SSL Handshake 과정 본격 분석

앞선 포스팅에 이어서, SSL Handshake는 클라이언트와 서버가 서로를 인증하고 안전한 통신을 위해 대칭키를 교환하는 과정이다.

 

즉, 서로 믿을 수 있는지 확인하고 암호화 통신 준비를 하는 과정이다.

 

 

 

 

SSL Handshake 과정을 요약한 그림이다.

 

 

실제 https 트래픽을 발생시켜 wireshark로 확인해보면 다음과 같다.

handshake를 한 이후에는 교환한 공개키로 암호화해서 데이터를 전송한다.

(암호화된 데이터를 복호화해서 http 트래픽으로 바꾸는 과정은 나중에 포스팅하겠다.)

 

 

 

 

이제 각 과정이 어떤 것을 의미하는지 하나하나 뜯어보자.

 

1. Client Hello : 클라이언트가 서버에 연결을 시도한다.

클라이언트가 브라우저 주소창에 https://www.naver.com을 치면 네이버 웹 서버에 접속을 시도한다.
HTTP는 TCP 기반으로 동작하기 때문에 브라우저는 TCP 3-way handshake를 수행하고 난 후, https의 ssl handshake를 위한 Client Hello를 보낸다.

Client Hello에는 다음과 같은 정보가 포함된다.

1. TLS/SSL 버전 정보
2. 브라우저가 생성한 랜덤 바이트
3. 세션 ID
   이전에 SSL Handshake가 완료되었다면 해당 세션 ID를 사용한다.
4. 클라이언트가 사용 가능한 Cipher suite 목록
   

   

   
   위 사진과 같이 일련의 암호화 방식을 패키지 형태로 묶어서 전달한다

2. Server Hello : 서버는 클라이언트의 Hello 패킷에 응답한다.

1. Cipher Suite
   클라이언트가 보낸 여러 개의 암호화 방식 중 하나를 선택하여 보낸다.
2. SSL Protocol Version

 

3. Certificate : 서버가 자신의 SSL 인증서를 전달한다.

SSL 인증서는 서버의 공개키가 포함되어 있고, 인증서는 CA의 개인키로 암호화되어 발급된 상태이다.
클라이언트는 해당 인증서를 CA의 공개키로 복호화하여 서버의 신뢰성을 인증한다.
SSL 인증서에는 다음과 같은 정보가 포함된다.

1. 서버가 발행한 공개키(PublicKey, 개인키는 서버가 소유한다.)

 

4. ServerKeyExchange : 서버의 공개키가 SSL 인증서 내부에 없는 경우, 서버가 직접 전달하는 패킷

공개키가 SSL 인증서 내부에 있다면 해당 과정은 생략된다. (인증서 내부에 공개키가 있으면 CA의 공개키를 통해 복호화하여 서버의 공개키를 획득할 수 있기 때문)

1. 키 교환 알고리즘 (여기서는 Diffie-Hellman을 사용)

 

5. ServerDone : 서버가 패킷 전송이 완료되었음을 알린다.

 

 

6. ClientKeyExchange : 클라이언트가 자신의 대칭키를 서버의 공개키로 암호화하여 전달한다.

클라이언트는 대칭키를 생성하고, SSL 인증서를 통해 추출한 서버의 공개키로 암호화하여 전달한다.
이후 해당 대칭키로 세션을 암호화한다.

 

7. Change Cipher Spec / Finished: 클라이언트, 서버 모두 SSL 통신을 위한 정보를 교환했고 통신할 준비가 완료되었음을 알린다.

 

 

8. Application Data: 암호화된 데이터

이후의 데이터들은 모두 암호화되어 통신한다.