(이 글에서 TLS과 SSL에 대한 정확한 명칭은 별도로 구분짓지 않습니다.)

TLS/SSL HandShake란?

Handshake는 클라이언트(브라우저)와 웹 서버가 안전한 암호화 통신을 시작하기 위해 서로 신분(서버의 신원 확인) 및 필요한 암호화 정보를 교환하는 과정이다.

클라이언트가 “이 암호화 방식으로 통신하자”라고 제안하면, 웹 서버가 이에 동의하고 인증서를 보내며, 이후 양측이 세션 키를 도출하는 과정이 포함되는 것이다.

CA란?

CA는 신뢰할 수 있는 인증 기관으로, 사용자가 접속하는 웹사이트가 진짜 해당 웹사이트임을 보장하는 역할을 한다.

이 기관의 주요 역할은, 사용자가 접속하는 웹사이트가 정말로 그 웹사이트가 맞는지를 보장하는 것이다.

예를 들어, 어떤 은행 사이트에 접속했을 때 그 사이트가 정말 그 은행이 맞는지 확인해주는 역할을 CA가 하는 것이다.

TLS/SSL HandShake에서 서버와 클라이언트는 어떻게 서로를 신뢰하게 될까?

현재 bank.com에 대한 도메인에 HTTPS를 적용한다고 가정해보자.

1. HTTPS를 적용하려면 bank.com의 웹 서버 관리자가

   • bank.com의 서버 자신의 공개 키
   • 도메인 정보
   • 조직 정보 등..

   위의 내용들을 포함하여 인증서 요청(CSR, Certificate Signing Request)을 생성한다.

2. CA는 이 요청을 검토하고, SSL 인증서를 발급해준다.

   SSL 인증서에는 아래의 정보들이 포함돼있다.

   • 해당 SSL인증서를 발급해준 CA의 정보
   • ❗ 요청을 보냈던 웹 서버(bank.com) 의 공개 키
   • 해당 웹 서버의 정보
     • 도메인 (bank.com)
     • 인증서 발급일
     • 그 외 각종 정보들

   이때, CA는 위의 SSL 인증서를 자신의 개인 키로 서명(Signing) 한다
   위 모든 SSL 인증서의 내용이 CA의 개인 키로 서명되어 있는 것이다.

   위 내용을 간단히 시각화 하면 아래와 같다.
   

3. 이렇게 CA의 개인키로 서명된 SSL 인증서를, 클라이언트가 CA의 공개 키를 사용하여 이 SSL인증서의 유효성을 검증하게 된다.

   브라우저(Chrome, Firefox 등)에는 기본적으로 신뢰할 수 있는 CA 리스트와 그들의 공개 키가 미리 내장되어 있다.

   그러므로 CA의 개인 키로 서명된 SSL인증서를 브라우저에 내장 된 공개키로 검증 할 수 있는 것이다.

   검증에 성공한다면, 이를 통해 이 SSL 인증서가 정말로 해당 CA가 발급한 것인지를 확인한다

   즉, SSL 인증서에 포함된 웹 서버 공개 키를 신뢰하게 되고, 보안 통신(HTTPS)을 진행하는 것이다.
   

TLS/SSL HandShake 시작

지금까지 진행된 바에 따르면,

• 웹 서버는 기본적으로 자신만의 개인 키를 보유하고 있다
• 클라이언트는 CA의 공개키를 기반으로 SSL인증서에 있는 웹 서버의 공개 키를 가지고 있다.

이렇게 비대칭키 전략 방식에 사용될 수 있는 환경이 구축됐다.

그러나, 실제로 HTTPS 통신은 비대칭키 + 대칭키 방식의 하이브리드 방식을 사용한다.

간단히 말하면 대칭키 방식으로 통신을 하되, 대칭키를 암호화/복호화 하는데 비대칭키를 사용하는 것이다.

• 파란색 상자의 패킷들은 TCP의 3-way handshake로 연결을 수립하는 것이고

• 노란색 상자의 패킷들이 TLS/SSL Handshake이다.

1. ClientHello

   • 클라이언트가 TLS 핸드셰이크를 시작

   • 이 메시지에는 클라이언트가 지원하는 TLS 버전, 암호화 알고리즘 목록, 압축 방법, 그리고 랜덤 데이터가 포함된다.

   이것은 "저는 이러한 보안 기능들을 지원하니, 이 중에서 선택해 주세요"라는 의미이다

2. ServerHello, Certificate, ServerHelloDone

   서버가 클라이언트의 요청에 응답

   • ServerHello

     서버가 사용할 TLS 버전과 암호화 알고리즘을 선택하여 알려준다

   • Certificate

     서버는 CA인증서의 개인 키로 서명되어있는 자신의 SSL인증서(위에 설명했던 SSL인증서)를 클라이언트에게 전송한다
     

     ❗ 아까 말했듯이, SSL인증서에 서버의 공개 키가 들어 있다. 그럼 클라이언트가 CA의 공개 키로 인증서의 서명을 검증 하게 되면 이 SSL 인증서는 CA가 서명한 것이 맞는 것이니 신뢰할 수 있는 서버의 공개 키를 확보할 수 있게 되는 것이다.
     

   • ServerHelloDone

     서버가 초기 메시지 전송을 완료했음을 알린다.
     

   이것은 "저는 이 보안 설정을 사용하겠고, 제 신원 증명은 여기 있습니다"라는 의미이다

3. ClientKeyExchange, ChangeCipherSpec, Finished

   • 클라이언트는 브라우저의 내장 CA 공개키를 통해 서버의 인증서를 복호화 한 후, 신뢰할 수 있는 서버의 공개 키를 확보하게 된다.

   • ClientKeyExchange
     

     1. 클라이언트는, 클라이언트와 서버가 실제로 교환하고자 하는 데이터의 암호화에 사용할 대칭 키를 생성한다
     2. 그리고 이전에 SSL 인증서 내부에서 추출한 서버의 공개 키를 이용해서 대칭 키를 암호화 한다.

   • ChangeCipherSpec

     클라이언트와 서버가 서로에게 보내는 메시지로

     1. 암호화한 대칭 키를 서버에게 전달하며
     2. 서버는 자신의 개인 키로 대칭 키를 복호화한다.
        

   • Finished

     TLS Handshake 과정을 마무리 짓고, 이제부터는 대칭 키를 사용해 안전하게 데이터를 주고받는다.

     

     "당신의 신원을 확인했고, 이제 이 대칭키를 사용해 암호화된 통신을 시작하겠습니다"라는 의미이다.

4. ChangeCipherSpec, Finished:

   • ChangeCipherSpec

     서버 역시 앞으로의 모든 통신은 합의된 암호화 방식으로 진행할 것임을 알린다.

   • Finished

     핸드셰이크 메시지의 해시를 암호화하여 전송함으로써 통신 무결성을 확인한다.
     

   서버 역시 "저도 암호화 통신을 시작할 준비가 되었습니다"라는 의미이다.

클라이언트가 서버의 공개 키를 이용해 데이터를 암호화하고 암호화된 데이터는 오직 서버만이 소유한 개인 키로 복호화할 수 있다.

여기까지만 하면 일반적인 비대칭키 방식이다.

그러나, 암호화/복호화 하는 데이터가 ‘대칭키’이며, 최종적으로 이 대칭키를 기반으로 HTTPS 통신을 진행하는 것이다.

---

출처 :

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

[네트워크] TLS & SSL Handshake

HTTPS를 위한 SSL/TLS 핸드 셰이크 작동원리