TLS 핸드셰이크 (TLS Handshake)

TLS 핸드셰이크(TLS handshake)는 클라이언트와 서버가 암호화 통신을 시작하기 전에 사용할 알고리즘을 협상하고, 서버의 신원을 인증서로 확인하며, 세션을 암호화할 키를 안전하게 합의하는 절차이다. 현재 표준인 TLS 1.3은 이 모든 과정을 왕복 한 번(1-RTT)에 끝내고, 재접속 시에는 0-RTT로 데이터를 함께 보낼 수도 있다. HTTPS 접속에서 브라우저 자물쇠 아이콘 뒤에 실제로 일어나는 일이 바로 이 핸드셰이크이며, 웹 보안의 사실상 출발점이라고 할 수 있다.

핸드셰이크가 해결하는 세 가지 문제

암호화 통신을 시작하려면 세 가지가 먼저 해결되어야 한다. 첫째, 양쪽이 지원하는 TLS 버전과 암호 스위트(cipher suite) 중 무엇을 쓸지 합의해야 한다. 둘째, 지금 대화하는 상대가 정말 그 도메인의 서버인지 확인해야 한다. 이것이 없으면 중간자 공격(man-in-the-middle attack)으로 공격자가 서버 행세를 할 수 있다. 셋째, 도청자가 있어도 둘만 아는 대칭키를 만들어야 한다. 핸드셰이크는 협상, 인증, 키 교환이라는 이 세 문제를 한 절차에 묶은 것이다. 키 교환의 핵심은 ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)로, 서로의 공개값만 주고받고도 제3자는 계산할 수 없는 공유 비밀을 양쪽이 각자 유도할 수 있다. 비밀 자체는 회선에 실리지 않으므로 전 구간을 도청당해도 안전하다는 점이 이 수학의 묘미다.

TLS 1.3 핸드셰이크의 과정

1. ClientHello: 클라이언트가 지원하는 암호 스위트 목록, 랜덤 값, 그리고 미리 만들어 둔 ECDHE 공개값(key share)을 함께 보낸다. 접속하려는 도메인은 SNI(Server Name Indication) 확장에 담긴다.
2. ServerHello: 서버가 암호 스위트를 선택하고 자신의 ECDHE 공개값과 랜덤 값을 보낸다. 이 시점에 양쪽 모두 공유 비밀을 계산할 수 있으므로, 이후 서버가 보내는 메시지부터 이미 암호화된다.
3. 서버 인증: 서버가 암호화된 채널로 인증서 체인을 보내고, 자신의 개인키로 핸드셰이크 내용 전체에 서명한 CertificateVerify를 보낸다. 클라이언트는 CA(Certificate Authority) 서명 사슬과 도메인 일치, 유효 기간을 검증하고 서명을 확인해 서버가 인증서의 개인키를 실제로 보유함을 확인한다.
4. Finished: 양쪽이 지금까지의 핸드셰이크 전체에 대한 검증값을 교환해 협상 과정이 변조되지 않았음을 확인한다. 여기까지 왕복 1회이며, 클라이언트는 Finished와 함께 첫 애플리케이션 데이터를 바로 실어 보낼 수 있다.
5. 이후 공유 비밀에서 파생한 세션 키와 AEAD(Authenticated Encryption with Associated Data) 알고리즘으로 데이터를 주고받는다.

세션 키는 방향별, 용도별로 여러 개가 파생되며, 핸드셰이크용 키와 애플리케이션 데이터용 키도 분리되어 있어 한 키가 노출되어도 피해 범위가 제한된다.