TLS 1.2의 2-RTT와 TLS 1.3의 1-RTT 핸드셰이크 구조를 단계별로 분석합니다. BEAST, POODLE 등 다운그레이드 공격의 원리와 TLS 1.3이 이를 구조적으로 차단하는 방식을 확인하세요.
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
TLS 1.2 핸드셰이크는 서버와 클라이언트 사이에 2번의 왕복(2-RTT)이 필요하다. TLS 1.3은 이를 1번(1-RTT)으로 줄였다. Qualys SSL Pulse 2025년 조사에 따르면 상위 웹사이트의 75.3% 가 TLS 1.3을 지원한다. 나머지 24.7%는 여전히 BEAST, POODLE 같은 다운그레이드 공격에 노출되어 있다.
이 글에서는 TLS 핸드셰이크가 어떻게 동작하고, 1.3이 무엇을 바꿨으며, 공격자가 어디를 노리는지 분석한다.
1990년대 초, 웹 브라우저와 서버 사이의 모든 통신은 평문(plaintext)이었다. HTTP 요청에 담긴 비밀번호, 신용카드 번호, 세션 쿠키가 네트워크 경로의 어느 지점에서든 읽을 수 있었다.
1994년, Netscape가 SSL(Secure Sockets Layer) 2.0을 발표했다. 목적은 단순했다 — 브라우저와 서버 사이에 암호화된 터널을 만드는 것. SSL은 이후 TLS(Transport Layer Security)로 진화했고, 현재 TLS 1.3(RFC 8446, 2018년)이 최신 버전이다.
핵심 질문은 이것이다. 브라우저가 서버에 처음 접속할 때, 어떤 암호 알고리즘을 쓸지, 어떤 키로 암호화할지 어떻게 합의하는가? 이 합의 과정이 TLS 핸드셰이크다.
TLS 핸드셰이크는 클라이언트와 서버가 암호화 통신을 시작하기 전에 수행하는 프로토콜 협상 과정이다.
The handshake can be thought of as having three phases: Key Exchange, Server Parameters, and Authentication. — RFC 8446, Section 2
핵심 구성 요소는 4가지다.
TLS 1.2 핸드셰이크는 2번의 왕복(Round-Trip)이 필요하다. 첫 번째 왕복에서 암호 스위트를 협상하고, 두 번째 왕복에서 키 교환을 완료한다.
다이어그램
각 단계를 분해하면 다음과 같다.
RTT 1 — 협상
클라이언트가 ClientHello를 보낸다. 이 메시지에는 지원하는 TLS 버전, 암호 스위트 목록, 클라이언트 랜덤값(32바이트)이 포함된다. 서버는 ServerHello로 응답하며, 암호 스위트를 하나 선택하고, 서버 랜덤값과 X.509 인증서를 전달한다.
// ClientHello 예시 (TLS 1.2)
ClientHello {
client_version: TLS 1.2 (0x0303)
random: 32바이트 난수
cipher_suites: [
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, // 선호 스위트
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA // 폴백 스위트
]
compression_methods: [null] // TLS 1.3에서 제거됨
}
RTT 2 — 키 교환
클라이언트는 서버 인증서를 검증한 후, ClientKeyExchange로 pre-master secret을 전달한다. 양측은 클라이언트 랜덤 + 서버 랜덤 + pre-master secret으로 마스터 시크릿을 도출하고, 이로부터 세션 키를 생성한다.
문제는 여기 있다. RTT 2가 완료되어야 첫 번째 암호화 데이터를 보낼 수 있다. 서울-미국 서버 간 RTT가 약 200ms라면, 핸드셰이크만으로 400ms가 소요된다.
TLS 1.3은 핸드셰이크를 근본적으로 재설계했다. 가장 큰 변화는 키 교환과 암호 스위트 협상을 첫 번째 메시지에 합친 것이다.
다이어그램
핵심 차이점 3가지를 분석한다.
TLS 1.2에서는 서버가 암호 스위트를 선택한 후에야 키 교환이 시작됐다. TLS 1.3에서는 클라이언트가 ClientHello에 키 공유값(key_share) 을 미리 포함한다. 서버가 응답할 때 이미 세션 키를 계산할 수 있어, 1-RTT로 줄어든다.
// ClientHello 예시 (TLS 1.3)
ClientHello {
supported_versions: TLS 1.3 (0x0304)
cipher_suites: [
TLS_AES_256_GCM_SHA384, // AEAD 전용
TLS_CHACHA20_POLY1305_SHA256
]
key_share: {
group: x25519,
key_exchange: 32바이트 공개키 // 키 교환이 첫 메시지에서 시작
}
// compression_methods 제거됨
// static RSA 키 교환 제거됨
}
TLS 1.2에서는 핸드셰이크 전체가 평문이었다. 서버 인증서, 지원 알고리즘 목록이 네트워크에 그대로 노출됐다. TLS 1.3에서는 ServerHello 이후의 모든 메시지가 암호화된다. 인증서조차 도청자가 볼 수 없다.
이것이 보안에 미치는 영향은 크다. 중간자(MITM)가 어떤 서버에 접속하는지 SNI(Server Name Indication)를 통해 도메인명은 알 수 있지만, 서버의 인증서 체인이나 협상 세부 사항은 확인할 수 없다.
이전에 접속한 서버에 다시 연결할 때, TLS 1.3은 0-RTT 모드를 지원한다. PSK(Pre-Shared Key)를 사용해 첫 메시지에 애플리케이션 데이터를 함께 보낸다. 연결 설정 시간이 사실상 0이 된다.
단, 0-RTT는 리플레이 공격에 취약하다. 공격자가 0-RTT 데이터를 캡처해 서버에 재전송할 수 있다. 이 때문에 0-RTT는 멱등(idempotent) 요청(GET 등)에만 사용해야 한다.
다이어그램
| 비교 항목 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 핸드셰이크 RTT | 2-RTT | 1-RTT (재접속 시 0-RTT) |
| 핸드셰이크 암호화 | 평문 | ServerHello 이후 암호화 |
| 키 교환 | RSA 또는 DHE (협상 후) | ECDHE 전용 (첫 메시지에 포함) |
| 암호 스위트 | CBC, RC4 등 레거시 포함 | AEAD 전용 (GCM, ChaCha20) |
| 전방향 비밀성 | 선택사항 | 필수 |
TLS 핸드셰이크의 역사는 곧 공격과 패치의 역사다. 공격자가 노리는 지점은 크게 3가지다.
POODLE(Padding Oracle On Downgraded Legacy Encryption, 2014)은 대표적인 다운그레이드 공격이다. 중간자가 핸드셰이크를 방해해 클라이언트와 서버가 SSL 3.0으로 폴백하도록 유도한다. SSL 3.0의 CBC 패딩 취약점을 이용해 암호화된 쿠키를 한 바이트씩 복호화할 수 있다.
TLS 1.3은 이 공격을 구조적으로 차단한다. 레거시 프로토콜(SSL 3.0, TLS 1.0, 1.1)을 완전히 제거했고, TLS_FALLBACK_SCSV 메커니즘으로 의도하지 않은 다운그레이드를 탐지한다.
BEAST(Browser Exploit Against SSL/TLS, 2011)는 TLS 1.0의 CBC 모드 구현 취약점을 공격한다. 초기화 벡터(IV)가 예측 가능하다는 점을 이용해, 같은 세션에서 전송되는 암호화된 데이터를 복호화한다.
TLS 1.3은 CBC 모드 자체를 제거했다. AEAD(Authenticated Encryption with Associated Data) 알고리즘만 허용한다 — AES-GCM과 ChaCha20-Poly1305. 암호화와 무결성 검증이 하나의 연산으로 결합되어, 패딩 오라클 공격이 원리적으로 불가능하다.
2011년 DigiNotar CA가 침해되어 *.google.com을 포함한 500개 이상의 위조 인증서가 발급됐다. 이란 사용자의 Gmail 통신을 감청하는 데 사용된 것으로 알려졌다. 핸드셰이크의 인증서 검증 단계가 아무리 견고해도, 신뢰 체인의 루트(CA)가 침해되면 무력화된다.
현재는 Certificate Transparency(CT) 로그가 의무화되어, 모든 인증서 발급이 공개 로그에 기록된다. 위조 인증서가 발급되면 즉시 탐지할 수 있다.
TLS 핸드셰이크는 0.1초 안에 벌어지는 암호화 협상이다. TLS 1.3은 2-RTT를 1-RTT로 줄이고, 핸드셰이크를 암호화하고, 레거시 알고리즘을 제거함으로써 성능과 보안을 동시에 개선했다.
핵심은 세 가지다. 키 교환을 첫 메시지에 합쳐 1-RTT를 달성했고, AEAD 전용으로 패딩 오라클 공격을 차단했고, 전방향 비밀성을 필수화해 키 유출 시에도 과거 세션을 보호한다.
| 글 | 링크 |
|---|---|
| HTTPS 보안의 실체 | 자물쇠 아이콘이 보장하는 것과 80%가 모르는 것 |
| HTTP 프로토콜 공격 표면 | 파싱 불일치가 만드는 5가지 보안 위협 |
| JWT 동작 원리 | 세션의 한계에서 토큰 인증까지 |
| OAuth 2.0 동작 원리 | 비밀번호 없는 인증이 필요한 이유 |
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.