HTTPS 통신과정 쉽게 이해하기 번외편(Perfect Forward Secrecy)

여러분은 오픈소스 패킷 분석 툴인 Wireshark(와이어샤크)를 자주 사용하시나요? 직무가 네트워크 엔지니어인 저는 꽤 자주 사용하는 편입니다. 통신이 안 되는 구간이 있다면 그 구간 내 어느 지점에서 패킷이 빠지는지 확인하거나 특이한 패킷이 있는지 살펴볼 때 유용하게 사용합니다. 

<패킷 분석 툴, Wireshark>

Wireshark를 사용하면 SSL Handshake뿐만 아니라 그 후에 지나가는 패킷도 캡쳐하여 저장할 수 있습니다. HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상)에서 제가 사용한 캡쳐화면 역시 Wireshark를 사용한 것입니다. SSL Handshake와 이후에 교환된 데이터를 모두 제 PC에 저장하는 것이죠. 그러나 해당 패킷들은 암호화되어 있기 때문에 제가 볼 수는 없습니다.

 

만약에 서버의 개인키를 탈취당한다면?(feat. RSA)

* RSA(로널드 라이베스트(R), 아디 샤미르(S), 레너드 애들먼(L) 이름의 앞글자) 암호
공개키 알고리즘입니다. 앞서 HTTPS 통신과정 #2에서 한 쌍의 공개키와 개인키가 있다고 말씀드렸던 게 기억나시나요? 바로 각기 다른 키인 공개키와 개인키를 이용하여 암호화/복호화하는 알고리즘입니다. 공개키로 암호화하여 개인키로 복호화하거나, 개인키로 암호화하여 공개키로 복호화합니다. 


출처: HTTPS 통신과정 쉽게 이해하기 #4(Cipher Suite)
 [네트워크 엔지니어 환영의 AWS 기술블로그]

앞선 문서에서 SSL Handshake에서 RSA가 키 교환 알고리즘으로 선택될 경우, Server는 한 쌍의 공개키와 개인키를 만들며 SSL 인증서를 통해 Client에게 공개키를 전달한다고 말씀드렸습니다. Client는 실제 데이터를 암호화하는데 사용할 비밀키(대칭키)를 생성하게 되고 이를 Server의 공개키로 암호화한 뒤 Server에게 전달하지요. 그리고 Server는 자신의 개인키로 암호화된 비밀키(대칭키)를 해독하고 Client와 Server는 같은 비밀키(대칭키)를 보유하게 됩니다. SSL Handshake에서 'Client Key Exchange'에 해당하는 부분입니다. 

<RSA, 비밀키(대칭키)를 교환하는 과정(출처 : blog.compass-security.com)>

앞으로 다시 돌아가서 제가 Wireshark를 통해 사용자와 서버의 SSL Handshake를 포함한 모든 암호화된 데이터를 확보한 상태임을 가정해보겠습니다. 제 컴퓨터에는 SSL Handshake 교환 과정의 모든 데이터가 저장되어 있습니다. 그리고 제가 불순한 의도를 가지고 서버에 접근하여 서버의 개인키를 탈취하는데 성공했습니다! 그럼 어떻게 될까요? 전 Wireshark를 통해 SSL Handshake의 모든 패킷을 확보했으므로 'Client Key Exchange'에 해당하는 패킷에서 전달된 '공개키로 암호화된 대칭키(비밀키)'를 개인키로 해독할 수 있게 됩니다. 그리고 해독된 대칭키(비밀키)를 통해 그동안 저장해온 모든 패킷을 복호화할 수 있게 됩니다. 즉 현재의 데이터뿐만 아니라 과거의 데이터 모두를 탈취당하는 것이지요.

 

비밀키(대칭키)를 교환하지 않는다면?(feat. Diffie-Hellman)

위의 문제는 RSA 키교환 방식에서 "Client Key Exchange"를 통해 결국 비밀키(대칭키)를 전달한다는 것에서 발생합니다. 아무리 암호화되어 있다하더라도 서버의 개인키를 탈취당한다면 비밀키(대칭키)를 얻을 수 있으므로 매우 위험해질 수 있습니다. 그렇다고 키를 자주 바꾸기도 어렵습니다. 앞 문서에서도 말씀드렸지만 RSA를 사용하는 경우 키교환 과정이 복잡합니다. 

* DH(Diffie-Hellman) 키 교환 
RSA와는 약간 다른 알고리즘이지만 데이터를 암호화/복호화하기 위해 하나의 키를 쓰는 알고리즘입니다. RSA가 공개키와 개인키를 생성하여 공개키를 모두에게 공개하는 것과 달리, DH 계열 알고리즘은 Parameter(매개변수), 즉 키를 생성할 재료를 교환합니다. 매개변수는 공개적으로 교환하며 노출되어도 상관없습니다. 매개변수를 교환한 후, Client와 Server 모두 동일한 대칭키(비밀키)를 얻게 됩니다. 


출처: HTTPS 통신과정 쉽게 이해하기 #4(Cipher-Suite)
 [네트워크 엔지니어 환영의 AWS 기술블로그]

하지만 Diffie-Hellman 키 교환 알고리즘(DH)은 사정이 다릅니다. Diffie-Hellman 키 교환 알고리즘은 SSL Handshake 실시 도중 'Client Key Exchange'에서 암호화된 대칭키(비밀키)를 교환하지 않습니다. 대칭키(비밀키)가 될 Parameter(매개변수)를 교환합니다. 이 재료들은 노출이 되어도 상관없는 존재들입니다. 그리고 각자 가진 고유의 값에 교환을 통해 갖게 된 Paramemter(매개변수)를 적용하여 동일한 비밀키(대칭키)를 만들고 이 키를 이용해 데이터를 암호화하지요.

<DH, 비밀키를 생성하는 과정(출처 : blog.compass-security.com)>

또한 Parameter(매개변수)만 교환하면 비밀키(대칭키)를 생성할 수 있기에 키교환 과정이 매우 간편합니다. 그렇기에 새로운 키를 만들기 매우 용이하지요. 이렇게 잠시동안 쓰고 새롭게 만들 수 있는일회성 키를 생성할 수 있는 Diffie-Hellman 키 교환 알고리즘을 Diffie-Hellman Ephermeral(DHE)이라고 합니다. Ephermeral은 '일회용'이라는 뜻이지요. Diffie-Hellman(DH)과 Diffie-Hellman Ephermeral(DHE)의 차이점입니다. DH보다는 DHE(Diffie-Hellman Ephermeral)와 ECDHE(Elliptic Curve Diffie-Hellman Exchange)의 사용을 권장하는 이유입니다.

 

Perfect Forward Secrecy(PFS)란?

위와 같은 DHE 키 교환 알고리즘의 특성을 사용하여 주기적으로 비밀키(대칭키)를 변경하여 특정 기간에는 특정한 비밀키(대칭키)로 데이터를 암호화하는 것을 Forward Secrecy(FS) 혹은 Perfect Forward Secrecy(PFS)라고 합니다. 데이터 교환이 이루어지는 내내 일회용 비밀키(대칭키)를 바꾸어 가면서 사용하는 것이지요. 특정 기간의 비밀키(대칭키)를 탈취당하더라도 피해는 '해당 특정 기간'에만 국한되기 때문에 안전합니다. 군대에서 매일매일 암구호를 바꾸어서 통신하듯이 말입니다. 그리고 앞서 말씀드린 것처럼 주기적인 키 교환이 가능한 DHE와 ECDHE만이 이 기능을 지원합니다. Parameter(매개변수)만 교환하면 손쉽게 비밀키(대칭키)를 생성할 수 있기 때문입니다. Diffie-Hellman 키 교환 알고리즘의 가장 큰 특징이지요.

<'www.naver.com'의 Cipher Suite>

네이버(www.naver.com) 접속시 사용할 수 있는 Cipher Suite 목록을 가져왔습니다. 각 줄의 가장 오른쪽에 'No FS' 혹은 'FS'가 보이시나요? 이것이 바로 Forward Secrecy의 약자인 'FS'입니다. 첫 번째 알고리즘은 RSA를 키 교환 알고리즘으로 사용하기 때문에 Forward Secrecy를 지원하지 않아 'No FS'라고 썼고 나머지 알고리즘들은 ECDHE를 사용하기에 Forward Secrecy를 지원해 초록색으로 'FS'라고 적어놨네요. 

<'www.naver.com'의 취약한 Cipher suite>

위 그림을 보면 대부분의 Cipher Suite가 취약(WEAK)하다고 언급되는데요. 3번째, 4번째 Cipher Suite는 MAC(메시지 인증 방식)이 'SHA1'이기에 취약하다고 나타내는 것입니다. 나머지 알고리즘은 SHA1 사용뿐만 아니라 키 교환 알고리즘이 'RSA'이기에 상대적으로 취약할 수 밖에 없습니다. 물론 RSA 암호 또한 매우 견고한 암호화 알고리즘이지만 서버의 '개인키'가 탈취당했을 때는 말이 달라집니다. 앞서 말씀드린 것처럼 RSA는 Perfect Foward Secrecy(PFS)를 지원하지 않기 때문이지요. 여기까지가 Perfect Forward Secrecy의 설명입니다. 감사합니다.

(오류지적 환영합니다!)