TLS Handshake

여러분이 웹사이트 주소창에 접속할 때 보이는 작은 자물쇠 아이콘의 의미를 생각해본 적 있나요? 이 작은 자물쇠 아이콘 뒤에는 생각보다 복잡하고 정교한 보안 메커니즘이 숨어 있습니다. 바로 TLS Handshake(Transport Layer Security)입니다.

HTTPS 기반의 웹 통신이나 민감한 정보를 다루는 서비스에서는 네트워크 상에서 정보가 노출되지 않도록 암호화가 필수입니다. 이때 사용되는 핵심 기술이 바로 TLS(Transport Layer Security)이며, 그 출발점이 되는 절차가 TLS Handshake입니다. TLS는 SSL의 후속 프로토콜로서 더 강력한 암호화와 성능을 제공하며, 오늘날 인터넷 보안의 표준으로 자리잡고 있습니다.

쉽게 말해 TLS 핸드셰이크는 클라이언트(예: 웹 브라우저)와 서버가 서로를 안전하게 믿고 통신하기 위해 진행하는 일종의 “악수”와 같습니다. 악수를 하듯, 서로의 신원을 확인하고 비밀스러운 정보를 공유하는 과정입니다. 이번 글에서는 TLS 핸드셰이크가 어떤 계층에서 동작하며, 어떤 메시지 흐름을 거쳐 세션 키를 안전하게 설정하고 서버 인증을 수행하는지 알아봅시다.

TLS 작동 계층

TLS는 전송 계층인 TCP 위에서 동작하며, OSI 7계층 모델에서는 세션 계층(Session Layer)과 응용 계층(Application Layer) 사이에 위치합니다. HTTP, SMTP, FTP 등의 애플리케이션 프로토콜 위에 TLS가 보안 계층으로 개입함으로써, 하위 계층에서의 연결 상태와 상위 계층에서의 데이터 흐름 사이에서 보안을 담당합니다. 이러한 구조 덕분에 TLS는 응용 프로토콜과 독립적으로 사용할 수 있으며, 데이터의 무결성과 기밀성을 보장합니다.

TLS와 TLS Handshake 차이

TLS(Transport Layer Security)는 네트워크상에서 데이터를 안전하게 전달하기 위한 보안 프로토콜의 일종입니다. TLS는 서버와 클라이언트 사이의 데이터 전송을 암호화하고 인증하여 보안을 유지합니다. 즉, TLS 자체는 보안 연결을 위한 프로토콜로서, 암호화, 인증, 무결성 보장 등을 포괄하는 개념입니다.

TLS Handshake는 TLS의 초기 연결 과정을 뜻합니다. 즉, 클라이언트와 서버가 서로 연결을 맺기 전 안전한 통신 채널을 구축하기 위해 필요한 초기 과정입니다. 이 단계에서는 다음과 같은 작업이 이루어집니다. 즉, TLS 핸드셰이크는 TLS라는 보안 프로토콜의 한 단계(초기 단계)로, 보안 연결을 형성하기 위한 필수적 과정입니다.

TLS는 보안된 연결을 위한 전체적인 보안 프로토콜의 개념이고, TLS 핸드셰이크는 TLS 프로토콜을 시작할 때 이루어지는 초기 보안 설정 과정입니다. 즉, TLS는 큰 개념이고, TLS 핸드셰이크는 그 안에서 연결을 안전하게 시작하기 위한 초기 단계입니다.

TLS 핸드셰이크의 목적

TLS 핸드셰이크는 단순한 연결이 아니라, 양측 간 신뢰를 형성하고 이후 보안 통신을 가능하게 하는 절차입니다. 주된 목적은 다음과 같습니다:

암호화 알고리즘 협상: 양측이 사용할 암호 스위트, 키 교환 방식, 해시 함수 등을 협상합니다.
인증서 기반의 신원 검증: 서버는 자신의 디지털 인증서를 통해 신원을 증명하고, 필요한 경우 클라이언트 인증도 수행합니다.
세션 키 생성 및 공유: TLS는 세션 키 기반의 대칭키 암호화를 사용하므로, 초기에는 공개키 암호를 활용해 세션 키를 안전하게 공유합니다.

핸드셰이크가 성공적으로 완료되면, 이후 모든 애플리케이션 데이터는 세션 키를 사용한 암호화된 상태로 교환됩니다.

TLS 핸드셰이크의 4가지 핵심 단계

TLS 핸드셰이크의 동작 원리를 쉽게 정리하면 다음과 같습니다.

1. 클라이언트 헬로우(Client Hello)

클라이언트는 ClientHello라는 메시지와 함께 등장합니다. 이 장에서는 클라이언트가 지원 가능한 TLS 버전(예: TLS 1.3), 사용할 수 있는 암호화 방식(예: AES-GCM, CHACHA20-POLY1305), 압축 옵션과 랜덤 값(ClientRandom)을 포함하여 서버로 보냅니다.

2. 서버 헬로우 및 인증(Server Hello & Authentication)

서버는 클라이언트의 제안을 검토한 후, 가장 적합한 TLS 버전과 암호화 방식을 선택해 ServerHello 메시지로 응답합니다. 이때 새로운 랜덤 값(ServerRandom)을 제시하여 대화의 방향을 함께 설정합니다. 이어서 서버는 자신의 정체성을 증명하기 위해 CA에서 발급받은 인증서를 Certificate 메시지로 내놓습니다. 클라이언트는 이 인증서를 검증하며 서버의 도메인 이름과 서명 유효성을 확인합니다.

3. 키 교환 및 암호 설정(Client Key Exchange & Key Derivation)

유효성이 확인되면, 클라이언트와 서버가 사용할 세션키(비밀키)를 만들어야합니다. 이러한 세션 키를 암호화 하기 위해서는 필효한 Master Secret 값을 만드는 방식으로는 아래의 2가지 방식(RSA 방식, DHE/ECDHE 방식) 중 하나를 사용합니다.

RSA 암호화 방식

클라이언트가 미리 무작위 숫자 하나(=Pre-Master Secret)를 생성하고, 서버의 공개키(인증서 안에 들어있음)로 암호화해서 서버로 보냅니다. 서버는 자신의 개인키로 복호화해서 같은 Pre-Master Secret 값을 얻게 됩니다.

클라이언트: 나는 랜덤 숫자 X를 사용하기로 확정하고, X를 서버 공개키로 암호화해서 서버에 보냅니다.
서버: 개인키로 암호 풀었더니 X를 확인합니다.
양쪽: X와 주고받은 랜덤 숫자(ClientRandom, ServerRandom)를 섞어 Master Secret 제작하고, Master Secret으로 실제 암호화·무결성 키 만들어 사용합니다.

DHE/DHEE와 ECDHE 암호화 방식

클라이언트와 서버가 서로 공개된 값을 주고받습니다. 그리고 서로 받은 값을 이용해 둘이 같은 비밀값을 각각 계산해 내는 방식입니다.

클라이언트: 클라이언트 공개키를 서버에 제공합니다.
서버: 서버 공개키를 클라이언트에 제공합니다.
클라이언트: 서버 공개키 보고, 혼자만의 비밀값 Y 계산합니다.
서버: 클라이언트 공개키 보고, 혼자만의 비밀값 Y 계산합니다.
다 같은 Y를 가지게 되고, 이 Y가 Pre-Master Secret 역할을 합니다.
Y와 주고받은 랜덤 숫자 두 개를 섞어 Master Secret 만들고, 실제 세션 키를 뽑아 사용합니다

인증이 완료되면, 클라이언트는 ClientKeyExchange 메시지로 Pre-Master Secret을 전달합니다. RSA 방식에서는 클라이언트가 생성한 Pre-Master Secret을 서버의 공개 키로 암호화해 보내고, DHE/ECDHE 방식에서는 양측이 공개값을 교환해 동일한 비밀값을 공동으로 생성합니다. 그 다음, 클라이언트와 서버는 ClientRandom, ServerRandom, Pre-Master Secret을 결합한 PRF(Pseudo-Random Function)를 통해 Master Secret을 생성합니다. 이 Master Secret은 대화에 사용할 세션 키(암호화 키와 MAC 키 등)를 파생하는 핵심 재료가 됩니다.

클라이언트는 이어서 ChangeCipherSpec 메시지로 이제부터 방금 만든 세션 키를 사용하겠다는 의사를 밝혀 암호화 모드로 전환 준비를 마치고, 암호화된 Finished 메시지를 보내 핸드셰이크 과정의 무결성을 확인합니다. ChangeCipherSpec을 보낸 후, 실제로 암호화된 Finished 메시지를 상대편에게 전송합니다. 이 Finished 메시지에는 핸드셰이크 동안 주고받은 모든 메시지(ClientHello, ServerHello, Certificate, KeyExchange 등)의 내용을 내부적으로 해시·계산해서 만든 검증 값(Verify Data)이 들어 있습니다. 이 두 단계를 마치면, 클라이언트와 서버는 완전히 서로 같은 세션 키를 가지고 있는 게 보장되고, 이후 오가는 모든 HTTP 요청/응답·데이터는 이 키로 암호화해서 안전하게 주고받을 수 있습니다.

Master Secret는 클라이언트와 서버가 핸드쉐이크 과정에서 합의한 공통의 비밀값을 의미하고, 세션 키들(Session Keys)는 Master Secret을 이용해 실제 암호화를 위해 뽑아낸 여러 개의 키를 의미합니다. 따라서 Master Secret은 세션 키를 만드는 원재료이고, 실제 데이터를 보호하는 것은 Master Secret이 아니라 그로부터 파생된 세션 키라고 할 수 있습니다.

4. 핸드셰이크 완료 및 암호화된 통신 시작(Connection Secured)

서버도 ChangeCipherSpec과 암호화된 Finished 메시지를 순차적으로 교환하며, 안전한 통신을 위한 마지막 절차를 끝냅니다. 그 후에 클라이언트와 서버는 완전한 보안 통로가 연결되었다고 판단하고, 이후 모든 애플리케이션 데이터는 세션 키로 암호화되어 교환됩니다.

TLS 1.3 vs TLS 1.2 비교

항목	TLS 1.2	TLS 1.3
핸드셰이크 메시지	10개 이상	6개 이하
알고리즘 구성	RSA, DH, ECDHE 등 다양	ECDHE 기반 PFS만 허용
0-RTT 지원	미지원	지원 (주의 필요)
보안 수준	SHA-1, RC4 등 여전히 존재	강제 제거, 보안성 향상
성능	2-RTT 이상 필요	1-RTT, 연결 속도 대폭 개선

TLS 핸드셰이크 주요 특징과 고려할 점

TLS 핸드셰이크는 높은 보안을 제공하지만 몇 가지 주의해야 할 사항이 있습니다.

지연(Latency): 핸드셰이크 과정에서 여러 번의 메시지 교환과 인증서 검증이 이루어지기 때문에, 첫 연결 시 약간의 지연이 발생할 수 있습니다. 이를 최소화하려면 TLS 세션 재사용(Session Resumption)을 설정하는 것이 좋습니다.
인증서 관리 및 갱신: 인증서 유효기간이 만료되거나 유효하지 않은 인증서를 사용하면 브라우저에서 경고 메시지가 표시되어 사용자 신뢰를 잃을 수 있습니다. 따라서 자동 갱신 및 모니터링이 필수적이라 할 수 있습니다.

정리

TLS 핸드셰이크는 단순히 연결을 여는 과정이 아니라, 이후 주고받을 모든 데이터를 안전하게 보호하기 위해 인증, 키 교환, 무결성 검증을 한꺼번에 처리하는 중요한 절차입니다. 클라이언트는 ClientHello 메시지로 지원하는 TLS 버전과 암호화 방식, 랜덤 값을 서버에 제안하고, 서버는 ServerHello와 함께 자신의 인증서를 보내어 “내가 믿을 수 있는 서버다”를 증명합니다. 클라이언트는 인증서를 검증한 뒤, 암호화된 프리마스터 시크릿을 전송해 양쪽이 공동의 세션 키를 만들 기반을 마련합니다. 이후 ChangeCipherSpec 메시지로 “이제부터 암호화 설정을 적용한다”고 알리고, Finished 메시지로 핸드쉐이크 전체의 무결성을 확인하면서 최종적으로 완전한 보안 채널을 수립합니다. 이 과정을 거쳐 키 합의, 메시지 위·변조 방지, 서버 인증 등이 모두 완료되므로, TLS 핸드쉐이크 이후 전송되는 애플리케이션 데이터는 안전하게 암호화된 상태로 오가게 됩니다.