TLS handshake

TLS handshake

HTTPS 프로토콜을 사용하기 위해 서버와 클라이언트가 수행하는 과정입니다. 해당 과정의 핵심은 보안 연결에 필요한 암호화 방식 교환, 암호화 키 생성과 TLS 인증서 인증 등이 있습니다.

3가지 작업에 대해서 설명하겠습니다.

Cipher Suites 교환 및 협상

클라이언트인 웹 브라우저는 Chrome, Safari, Firefox 등 다양한 브라우저가 존재하고 서버도 Nginx, Apache 등 다양한 환경으로 구성됩니다. 각각의 구성 환경에서 제공되는 기능은 다양하기 때문에 우선 클라이언트와 서버에서 사용할 암호화 방식을 선정해야됩니다.

이것이 TLS handshake 의 첫번째 역할이며 클라이언트는 사용 가능한 암호화 방식(Cipher Suites) 를 보내며 서버는 암호화 방식(Cipher Suite)을 선정하여 TLS 인증서를 전송하게 됩니다.

인증서 인증

클라이언트는 서버가 전송한 TLS 인증서를 검증하는 작업이 필요합니다.

신뢰 가능한 보안 연결에 필수적인 작업으로 TLS 인증서 검증을 통해 클라이언트가 통신을 시작할 서버가 신뢰할 수 있는 웹사이트인지 판단합니다.

TLS 인증서의 구성과 검증 과정은 아래의 링크에서 더 자세히 확인할 수 있습니다.

TLS 인증서 체인

또한 이 과정에서 인증서가 검증이 되었다면 서버의 개인키 역시 확인해야 합니다. 모든 TLS 인증서는 서버의 공개키도 구성되어 있으며 해당 공개키의 쌍인 서버의 개인키가 유효한지 검증 작업도 수행해야 합니다.

Session Key 생성 및 교환

TLS handshake 의 마지막 작업으로 실제 보안 통신에 사용할 “Session Key” 를 구성하여 교환해야 합니다.

Session Key 는 대칭키로 구성됩니다. 비대칭키는 암호화 복호화 작업에 대해서 리소스 자원이 많이 들게 되므로 대칭키를 사용하여 보다 효율적은 보안 통신을 수행합니다.

TLS handshake 에서 키 교환까지 완료되면 서버와 클라이언트는 각각 작업의 완료를 알리며 체크섬을 통해 handshake 과정에서 변조나 손상이 없는지 확인합니다.

TLS Handshake 과정

이제 위에서 설명한 TLS handshake 역할의 수행과정(TLS 1.2)을 알아보겠습니다.

Client Hello

가장 처음 전송되는 패킷으로 ClientHello 입니다.

해당 패킷에는 Cipher Suites 교환 및 협상 을 위해 클라이언트가 해독할 수 있는 Ciper Suties 를 전달합니다.

추가로 클라이언트에서 생성한 32 byte 난수가 해당 패킷에 포함되어 있습니다.

Server Hello

Client Hello 패킷을 수신한 서버는 Server Hello 패킷으로 응답합니다.

해당 패킷에는 수신한 Cipher Suite 목록에서 선정된 암호화 방식이 구성되어 있습니다. 이 과정에서 서버와 클라이언트 사이 공통된 사용 가능한 암호화 방식이 없으면 연결이 종료됩니다.

Client Hello 와 마찬가지로 서버에서 생성한 32 byte 난수가 구성되어 있습니다.

Certificate

서버의 인증서 체인(서버 인증서, 중간 인증서)을 전송하는 Certificate 패킷입니다.

인증서 체인을 수신한 클라이언트는 인증서 인증 과정을 수행하며 인증서 체인 유효성, 인증서 전자 서명, 인증서의 표기된 서버의 정보(도메인, 이메일 등)을 검사합니다.

Client Certificate Request(Optional)

선택적으로 서버는 클라이언트의 인증서를 요청하는 경우가 있습니다.

해당 경우는 보통 서버와 서버의 통신 과정에서 발생합니다. Client Certificate Request 패킷을 수신하면 서버가 클라이언트의 인증서 유효성 검사를 진행할 것 입니다.

Server Hello Done

인증서 교환이 완료되면 Server 는 클라이언트에게 모든 패킷 전송이 완료됨을 Server Hello Done 패킷으로 알립니다.

Client Key Exchange

클라이언트에서 서버의 인증서 유효성 검증을 완료하면 Session Key 를 교환해야 합니다. 해당 과정은 Hello 패킷 과정에서 선정된 암호화 방식에 따라 다릅니다.

우선 Client 는 Pre Master Secret 이라는 48 바이트 난수를 하나 생성하며 앞서 Hello 패킷 과정으로 선정한 암호화 방식(현재 예로는 ECDHE)과 서버의 공개키로 암호화 하여 Client Key Exchange 패킷에 담아서 전송합니다.

Change Cipher Spec(Client)

Client 가 생성한 Pre Master Secret 과 서버의 난수, 클라이언트의 난수와 앞서 hello 패킷 과정에서 선정한 암호화 방식의 해시 함수(현재 예로는 SHA)을 이용하여 Session Key(Master Secret) 을 생성합니다.

그후 Client 는 앞으로 암호 통신으로 전환을 Change Ciper Spec 패킷으로 알립니다.

Finished(Client)

Client 는 마지막으로 handshake 의 종료를 Finished 패킷으로 알립니다.

Change Cipher Spec(Server)

서버는 클라이언트에게 수신한 Client Key Exchange 의 암호화된 값을 서버의 개인키로 복호화하여 클라이언트가 생성한 Pre Master Secret 값 얻습니다.

클라이언트와 마찬가지로 서버는 Pre Master Secret 과 서버, 클라이언트의 난수를 통해 해시 함수를 이용하여 Session Key(Master Secret) 을 생성합니다.

그후 앞으로 암호 통신으로 전환을 Change Cipher Spec 으로 클라이언트에게 알립니다.

Finished(Server)

마지막으로 Server 도 handshake 과정의 종료를 Finished 패킷으로 알립니다.

Session Key 생성의 다른 과정

모든 TLS handshake 과정에서 Session Key 를 생성하기 위하여 서버의 개인키를 사용하는 방식이 아닙니다.

Diffie-Hellman 알고리즘을 사용하여 Session Key 를 생성하는 TLS handshake 과정은 따로 존재합니다. 해당 과정은 추후의 다른 포스트에서 정리하겠습니다.

참고자료

wireshark tls handshake

클라이언트 인증서 + hadnshake Deep Dive

tls handshake

tls handshake 요약