반응형

HTTP(Hypertext Transfer Protocol)

※ 기본 포트 : 80

인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약.

다음과 같은 단점이 있다.

  1. 텍스트 기반 프로토콜: HTTP는 텍스트 명령을 사용하여 요청과 응답을 주고 받음.
    - 기본 HTTP는 데이터가 평문으로 전송되므로, 중간에 패킷을 가로채기 쉬움
  2. 무상태 프로토콜: 각 요청과 응답이 독립적이며, 서버는 이전 요청에 대한 정보를 유지하지 않음.
    - 웹 애플리케이션이 각 요청에 대해 별도로 인증 및 상태 정보를 전송해야 함을 의미
    - 헤더 오버헤드 : 쿠키, 사용자 에이전트, 각종 커스텀 헤더 등이 요청마다 반복적으로 전송 -> 대역폭과 리소스 소모 증가

 

 

 

HTTP(Hypertext Transfer Protocol Secure)

※ 기본 포트 : 443

인터넷 상에서 정보를 암호화하는 SSL/TLS 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약.

 

 

 

인증서

인증서는 주체에 대한 정보, 공개키에 대한 정보를 포함하는 단순한 데이터 파일이다.

  • 주체에 대한 정보 : 인증서 발급한 CA, 도메인, 웹사이트 소유자, 인증서 소유자
  • 공개키에 대한 정보 : 공개키, 공개키암호화방법

주체는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 확인할 때 쓰이고 공개키는 처음 인증작업을 수행할 때 쓰임.

인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 한다. 

 

 

 

CA(Certificate Authority)

인증서를 발급하는 기업들을 CA라고 함. 보통은 인증기관인 CA에서 발급한 SSL인증서를 기반으로 인증작업을 수행함.

CA로 부터 인증서 구입 시 서비스의 도메인, 공개키와 같은 정보를 제출해야 함.

 

CA로부터 인증서 활용 과정

1. 서버A가 HTTPS를 적용하기 위해 비대칭키(공개키/개인키) 생성

2. CA 기업에 서비스 도메인, 공개키 제출.

3. CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법 등을 담은 인증서를 생성.

4. 인증서를 CA기업의 개인키로 암호화 하여 A서버에게 제공. (CA기업의 공개키는 브라우저가 이미 알고 있다.)

5. A서버에는 처음 클라이언트에게 이 암호화된 인증서를 건내줌.

6. 클라이언트는 CA기업의 공개키로 인증서 해독하여 A서버의 공개키를 얻게 됨.

이제 클라이언트는 이 공개키로 세션을 생성해서 암호화 하여 A서버와 통신.

 

 

 

SSL (Secure Sockets Layer)

데이터 암호화, 인증, 무결성을 중심 기능으로 하는 프로토콜.

1990년대 넷스케이프(Netscape)에서 처음 개발됨.

SSL 3.0도 여전히 몇몇 보안 문제를 가지고 있음.

이후 TLS 1.0을 지나 1.3버전이 되면서 아예 TLS로 명칭 변경됨.

 

 

 

TLS (Transport Layer Security)

SSL기반의 후속 프로토콜. SSL과 마찬가지로 암호화, 인증, 무결성을 중심 기능으로 함. 더 안전하고 효율적.

TLS Handshake : 세션키를 (대칭키로) 생성하는 과정! 

 

TLS handshake (RSA)

  1. Client : ClientHello
    • 클라이언트가 핸드셰이크를 시작. 클라이언트는 ClientHello 메시지를 서버에 보냄
      (지원하는 암호 스위트 목록, 클라이언트의 랜덤 값, 지원하는 키 교환 방법, 프로토콜 버전이 포함됨)
  2.  Server : ServerHello, Certificate, Done
    • ServerHello:
      서버는 응답으로 ServerHello 메시지를 보냄
      (선택된 암호 스위트, 서버의 랜덤 값, 그리고 서버가 선택한 키 교환 방법이 포함됨)
    • Certificate:
      서버는 자신의 인증서를 클라이언트에 전송. (공개 키 전송)
    • ServerHelloDone:
      이후, 서버는 핸드셰이크 준비가 완료되었음을 알리고 클라이언트의 응답을 기다림
  3. Client : Client Key Exchange, Create Session key, Change Cipher Spec Request, Finished
    • Client Key Exchange :
      클라이언트는 서버에게 받은 공개키를 이용해서 프리마스터 시크릿을 암호화 한 후, Client Key Exchange 메시지를 통해 서버에 프리마스터 시크릿을 전송 (프리마스터 시크릿은 TLS 세션에서 생성되는 비밀 값으로, 클라이언트와 서버가 대칭 키를 생성하는 데 사용)
    • Create Session key:
      클라이언트는 프리마스터 시크릿, 서버 랜덤값, 클라이언트 랜덤값 등을 사용하여 동일한 세션키(대칭키)를 만듦.
    • Change Cipher Spec Request :
      클라이언트는 Change Cipher Spec 메시지를 보내, 이후의 통신이 암호화될 것임을 알림
    • Finished :
      클라이언트는 Finished 메시지를 보내 핸드셰이크가 완료되었음을 알림
  4. Server : Create Session key, Change Cipher Spec Respons , Finished
    • Create Session key:
      서버는 암호화된 프리마스터 시크릿을 개인키로 복호화 함
      서버는 프리마스터 시크릿, 서버 랜덤값, 클라이언트 랜덤값 등을 사용하여 동일한 세션키(대칭키)를 만듦
    • Change Cipher Spec Respons :
      서버는 클라이언트와 마찬가지로 Change Cipher Spec 메시지를 보내, 이후의 통신이 암호화될 것임을 알림
    • Finished :
      서버는 Finished 메시지를 보내 핸드셰이크가 완료되었음을 알림 (핸드셰이크 메시지의 무결성을 검증하는 정보를 포함)
  5. 안전한 대칭 암호화 성공: 
    • 핸드셰이크가 완료되고, 세션 키를 이용해 통신이 계속 진행.

 

TLS handshake (Diffie-Hellman)

위의 방식처럼 RSA의 개인키를 사용하지 않는 대신 Diffie-Hellman 알고리즘(지수 계산)을 이용해 동일한 예비 마스터 암호를 생성함.

서버와 클라이언트가 각자 계산을 위한 매개변수를 제공하고, 각자 서로 다른 계산 결과가 나오지만, 합치면 결과가 동일해짐.

RSA방식과 다른 점은 클라이언트와 서버가 서로 교환한 DH 매개변수를 사용하여 일치하는 예비 마스터 암호를 별도로 계산한다는 것.

 

  1. Client : ClientHello
    • 클라이언트가 핸드셰이크를 시작. 클라이언트는 ClientHello 메시지를 서버에 보냄
      (지원하는 암호 스위트 목록, 클라이언트의 랜덤 값, 지원하는 키 교환 방법, 프로토콜 버전이 포함됨)
  2.  Server : ServerHello, Server Key Exchange, Certificate, Digital signature
    • ServerHello:
      서버는 응답으로 ServerHello 메시지를 보냄
      (선택된 암호 스위트, 서버의 랜덤 값, 그리고 서버가 선택한 키 교환 방법이 포함됨)
    • Server Key Exchange:
      서버는 DH 매개변수를 통해 계산된 공개키를 전송
    • Certificate:
      서버는 자신의 인증서를 클라이언트에 전송. (공개 키 전송)
    • Digital signature
      서버는 이 시점까지의 모든 메시지에 대한 디지털 서명을 계산
  3. Client : Client Key Exchange, Create Session key, Change Cipher Spec Request, Finished
    • Client Key Exchange :
      서버의 디지털 서명을 통해 서버의 신뢰성을 확인하면, 클라이언트는 자신의 DH 매개변수를 통해 계산된 공개키를 Client Key Exchange 메시지를 통해 전송
    • Create Session key:
      DH 매개변수를 사용하여 서로의 공개 키를 기반으로 동일한 비밀 키를 계산
    • Change Cipher Spec Request :
      클라이언트는 Change Cipher Spec 메시지를 보내, 이후의 통신이 암호화될 것임을 알림
    • Finished :
      클라이언트는 Finished 메시지를 보내 핸드셰이크가 완료되었음을 알림
  4. Server : Create Session key, Change Cipher Spec Respons , Finished
    • Create Session key:
      DH 매개변수를 사용하여 서로의 공개 키를 기반으로 동일한 비밀 키를 계산
    • Change Cipher Spec Respons :
      서버는 클라이언트와 마찬가지로 Change Cipher Spec 메시지를 보내, 이후의 통신이 암호화될 것임을 알림
    • Finished :
      서버는 Finished 메시지를 보내 핸드셰이크가 완료되었음을 알림 (핸드셰이크 메시지의 무결성을 검증하는 정보를 포함)
  5. 안전한 대칭 암호화 성공: 
    • 핸드셰이크가 완료되고, 세션 키를 이용해 통신이 계속 진행.

 

TLS 1.3 handshake

위의 과정들에서 많이 간소화 됨.

1. Hello 메세지를 보낼 때 DH 매개변수를 만들어 같이 보냄.

2. Change Cipher Spec이 생략.

3. Client Key Exchange 과정이 세션 키 생성 과정과 통합.

 

  1.  ClientHello
    • 클라이언트가 핸드셰이크를 시작. 클라이언트는 ClientHello 메시지를 서버에 보냄
      (암호 목록, 클라이언트의 랜덤 값, DH 매개변수, 프로토콜 버전이 포함됨)
  2. ServerHello, Certificate, Encrypted Extensions, (+ CertificateVerify), Session, Done
    • ServerHello:
      서버는 응답으로 ServerHello 메시지를 보냄
      (선택된 암호 스위트, 서버의 랜덤 값, DH 매개변수 등이 포함됨)
    • Certificate:
      서버는 자신의 인증서를 클라이언트에 전송. (공개 키 전송)
    • Encrypted Extensions:
      추가 확장 정보를 제공. 선택한 암호 스위트에 따라 다를 수 있는 추가 옵션을 포함
    • 클라이언트에게 받은 값으로 
    • CertificateVerify:
      클라이언트 인증을 요구하는 경우, 서버는 클라이언트에게 CertificateVerify 메시지를 요청
  3. Create Session key, Finished
    • Create Session key:
      서버와 클라이언트는 공유된 DH매개변수를 사용하여 세션키를 생성.
    • Finished :
      Finished 메시지를 보내 핸드셰이크가 완료되었음을 알림.
  4. 안전한 대칭 암호화 성공: 
    • 핸드셰이크가 완료되고, 세션 키를 이용해 통신이 계속 진행.

TLS 1.3 핸드셰이크는 이전 버전과 달리, 핸드셰이크 과정에서 대칭키가 교환되고 나면 모든 후속 핸드셰이크 메시지도 암호화된다.

 

 

 

0-RTT ((Zero Round Trip Time)

TLS 1.3에서는 0-RTT handshake를 지원한다. 이 기능은 이전에 연결된 적이 있는 클라이언트가 서버와 재연결할 때 사용할 수 있다.

 

  • ClientHello with Early Data
    • 클라이언트는 이전 세션의 PSK(Pre-Session Key)를 사용하여 ClientHello 메시지와 함께 초기 데이터를 서버에 보냅니다.
    • 이 초기 데이터는 암호화되어 전송됩니다.
  • ServerHello with Early Data
    • 서버는 클라이언트의 ClientHello 메시지를 수신하고, PSK를 검증합니다.
    • 서버는 ServerHello 메시지와 함께 초기 데이터를 클라이언트에 보냅니다.

 

 위의 과정이 0-RTT 내에 완료됨.

※ 0rtt psk 는 보안에 취약하지 않나?

  • 0-RTT는 재전송 공격에 취약할 수 있으므로, 중요한 작업이나 상태 변경 요청에는 사용하지 않는 것이 좋습니다.

 

 

 

HTTP/3.0 과 HTTPS 와의 관계

QUIC는 전송 프로토콜로은 보안 측면에서 TLS 1.3을 기본적으로 통합하여 데이터를 암호화.

HTTP/3.0은 QUIC 위에서 동작하므로  무조건 HTTPS.

 

HTTPS 는 무조건 HTTP/3.0이다? X

HTTP 버전에 SSL/TLS 를 추가하면 HTTPS이다. 때문에 HTTP/1.1, HTTP/2.0, HTTP/3.0 모두 가능.

 

  

 

 

 

 

728x90
반응형

'Computer Science > Network' 카테고리의 다른 글

HTTP/1.0, HTTP/1.1, HTTP/2.0, HTTP/3.0(QUIC)  (2) 2024.09.30
암호화 - 단방향 vs 양방향, 대칭키 vs 비대칭키(개인키/공개키), 암호화 알고리즘  (0) 2024.09.25

티스토리툴바