HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상)

고대 그리스에서는 타인에게 노출되어서는 안 될 중요한 정보를 보낼 때, 전달하는 이(사자)의 머리를 빡빡 깎아서 중요한 정보를 적은 후 머리가 자라서 글이 보이지 않으면 그제야 상대방에게 보냈다고 합니다. 그리하게 되면 그 사실을 모르는 사람은 정보를 볼 수 없고 사실을 아는 수신자는 다시 머리를 깎은 후 정보를 볼 수 있을 테니까요. 이 암호 기법을 스테가노그래피라고 합니다.

 

<고대 그리스의 정보 전달방법, 스테가노그래피(출처 : EBS MATH)>

그 당시로서는 정말 획기적인 방법이 아닌가 싶습니다. 누가 두피에 글을 적어서 보낼 거라고 예상을 할까요? 물론 머리가 다 자라라면 한참 걸린다는 단점이 존재하지만 들키지 않는 데는 이만한 방법이 없는 것 같습니다. 그만큼 중요한 정보를 안전하게 보내는 것이 가장 중요했기 때문이겠지요. 세 번째 그림에서 보니 동그라미 속 수신자는 반가운 얼굴로 사자를 맞이하네요. 그게 의미하는 것이 뭘까요? 바로 수신자와 송신자가 전달방법에 대해 이미 공유하고 있으며, 사자가 온 이유를 알고 있다는 뜻입니다.

 

HTTPS 통신과정에서도 송신자와 수신자가 암호화 통신을 하기 위한 방법과 수단에 대해 공유합니다. 즉 데이터를 암호화할 대칭키(비밀키)를 타인에게 노출시키지 않고 Client가 Server에게 전송하기 위해 협상을 벌이는 것이죠. 이번에 다룰 SSL Handshake(TLS Handshake)가 그 방법으로, 송신자와 수신자가 암호화된 데이터를 교환하기 위한 일련의 협상과정을 의미합니다. 협상과정에는 SSL 인증서 전달, 대칭키(비밀키) 전달, 암호화 알고리즘 결정, SSL/TLS 프로토콜 결정 등이 포함됩니다.

 

<SSL handshake의 과정(출처 : Cloudflare)>

SSL Handshake의 과정을 그린 그림을 가져왔습니다. 여기 파란색 칸과 노란색 칸은 네트워크 상에서 전달되는 IP Packet을 표현한 것입니다. 맨 윗줄의 SYN, SYN ACK, ACK는 TCP layer의 3-way handshake로 HTTPS가 TCP 기반의 프로토콜이기 때문에 암호화 협상(SSL Handshake)에 앞서 연결을 생성하기 위해 실시하는 과정이고 아래 노란색 상자의 패킷들이 SSL Handshake입니다. 

1. 암호화 알고리즘(Cipher Suite) 결정

2. 데이터를 암호화할 대칭키(비밀키) 전달

 

위 두 가지를 기억하면서 순서대로 보시길 권장합니다.

 

Client Hello

Client가 Server에 연결을 시도하며 전송하는 패킷입니다. 자신이 사용 가능한 Cipher Suite 목록, Session ID, SSL Protocol Version, Random byte 등을 전달합니다. Cipher Suite는 SSL Protocol version, 인증서 검증, 데이터 암호화 프로토콜, Hash 방식 등의 정보를 담고 있는 존재로 선택된 Cipher Suite의 알고리즘에 따라 데이터를 암호화하게 됩니다. 아래 사진을 보면 Client가 사용 가능한 Cipher Suite를 Server에 제공하는 것을 알 수 있습니다.

<Clienthello Packet>

<Cipher Suite의 구성>

 

Server Hello

Client가 보내온 ClientHello Packet을 받아 Cipher Suite 중 하나를 선택한 다음 Client에게 이를 알립니다. 또한 자신의 SSL Protocol Version 등도 같이 보냅니다. 아래 사진을 보면 ClientHello에서 17개였던 Cipher Suite와 달리 아래에서는 Server가 선택한 한 줄(Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)만이 존재하는 것을 알 수 있습니다.  Client가 보낸 리스트에 있는 Cipher Suite 중에 한 개를 선택한 것이지요.

<ServerHello Packet>

반응형

Certificate

Server가 자신의 SSL 인증서를 Client에게 전달합니다. 인증서 내부에는 Server가 발행한 공개키(+개인키는 Server가 소유)가 들어있습니다. Client는 Server가 보낸 CA(Certificate Authority, 인증기관)의 개인키로 암호화된 이 SSL 인증서를 이미 모두에게 공개된 CA(Certificate Authority, 인증기관)의 공개키를 사용하여 복호화합니다. 복호화에 성공하면 이 인증서는 CA(Certificate Authority, 인증기관)가 서명한 것이 맞는 것이니 진짜임이 증명되는 것이죠. 즉, 인증서를 검증하는 것입니다.

 

또한 Client는 데이터 암호화에 사용할 대칭키(비밀키)를 생성한 후 SSL 인증서 내부에 들어 있던 (Server가 발행한) 공개키를 이용해 암호화하여 Server에게 전송할 것입니다. 아래를 보면 SSL 인증서가 무슨 알고리즘(RSA)으로 암호화되었고, 무슨 Hash 알고리즘(SHA256)으로 서명되었는지 확인 가능합니다.

<Certificate Packet>

 

Server Key Exchange / ServerHello Done

'Server Key Exchange'는 Server의 공개키가 SSL 인증서 내부에 없는 경우, Server가 직접 전달함을 의미합니다. 공개키가 SSL 인증서 내부에 있을 경우 Server Key Exchange는 생략됩니다. 인증서 내부에 공개키가 있다면 Client가 CA(Certificate Authority, 인증기관)의 공개키를 통해 인증서를 복호화한 후 Server의 공개키를 확보할 수 있습니다. 그리고 Server가 행동을 마쳤음을 전달합니다.

<Server Key Exchange>

위의 경우, 키 교환 알고리즘이 Diffie-Hellman(DH, DHE 등) 알고리즘이기에 키 교환 재료를 서로 교환하므로 'Server Key Exchange'를 발생시키는 것입니다. 아래 'Client Key Exchange'에서 자세히 설명합니다. 

 

Client Key Exchange

대칭키(비밀키, 데이터를 실제로 암호화하는 키)를 Client가 생성하여 SSL 인증서 내부에서 추출한 Server의 공개키를 이용해 암호화한 후 Server에게 전달합니다. 여기서 전달된 '대칭키'가 바로 SSL Handshake의 목적이자 가장 중요한 수단인 데이터를 실제로 암호화할 대칭키(비밀키)입니다. 이제 키를 통해 Client와 Server가 교환하고자 하는 데이터를 암호화합니다.

<Client Key Exchange>

 

위의 캡쳐화면을 보고 의아한 생각이 드실겁니다. Client가 데이터를 암호화할 대칭키(비밀키)를 보낸다고 했는데 'EC Diffie-Hellman Client Params', 즉 키를 생성할 재료를 보낸다는 것으로 보이네요. 키교환 알고리즘을 RSA가 아닌 Diffie-Hellman(DH, DHE 등) 알고리즘과 타원곡선 암호인 ECDHE(Elliptic Curve DHE)을 사용하게 된다면 Client가 데이터를 암호화할 대칭키(비밀키)를 보내는 것이 아니라 대칭키(비밀키)를 생성할 재료를 Client와 Server가 교환하게 됩니다. 그리고 서로 교환한 각자의 재료를 합쳐 동일한 대칭키를 만들 수 있답니다. Diffie-Hellman(DH, DHE 등)과 타원곡선 암호인 ECDHE(Elliptic Curve DHE)의 특징입니다. RSA 키교환 알고리즘을 사용하게 되면 Client가 대칭키(비밀키)를 생성하여 인증서 내부에 들어 있던 서버의 공개키로 암호화 한 후 전달하게 됩니다.

 

ChangeCipherSpec / Finished

Client, Server 모두가 서로에게 보내는 Packet으로 교환할 정보를 모두 교환한 뒤 통신할 준비가 다 되었음을 알리는 패킷입니다. 그리고 'Finished' Packet을 보내어 SSL Handshake를 종료하게 됩니다.

<Change Cipher Spec>

여기까지가 SSL Handshake입니다. 요약해보면 ClientHello(암호화 알고리즘 나열 및 전달) - > Serverhello(암호화 알고리즘 선택) - > Server Certificate(인증서 전달) - > Client Key Exchange(데이터를 암호화할 대칭키 전달) - > Client / ServerHello done (정보 전달 완료) - > Finshied (SSL Handshake 종료) 이정도로 나열할 수 있습니다. 과정이 끝나면 Client와 Server는 데이터를 암호화할 동일한 대칭키(비밀키)를 갖게 되며, 서로에게 각자 갖고 있는 동일한 대칭키를 통해 데이터를 암호화하여 전송하거나 데이터를 복호화합니다. Client와 Server는 이제 성공적으로 비밀친구가 되었습니다.

 

여기까지가 SSL Handshake의 과정에 대한 전반적인 내용입니다. 사실 RSA나 DHE와 같은 알고리즘에 대한 언급이 없다보니 약간 나사가 빠진 기분이 드네요. 그래서 다음 편에 Cipher Suite를 다룰 예정인데요. Cipher Suite를 이해하시고 나면 좀더 쉽게 느껴지지 않을까 생각합니다. 감사합니다.