0Pricing
Cryptology Academy · 강의

TLS 1.3: 0-RTT, 조기 데이터 및 세션 재개

TLS 1.3 세션 티켓, 0-RTT의 재생 공격 방지 한계, PSK 세션 재개 보안을 이해합니다.

TLS 1.3: 0-RTT, 조기 데이터 및 세션 재개은(는) CoddyKit의 무료 Cryptology Academy 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Cryptology Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Cryptology Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

TLS 1.3 핸드셰이크 개요

TLS 1.3(RFC 8446, 2018)은 지연 시간을 줄이고 기존의 불필요한 요소를 제거하기 위해 TLS 핸드셰이크를 재설계했습니다. 전체 TLS 1.3 핸드셰이크는 1-RTT로 완료됩니다. 클라이언트는 첫 번째 전송에서 지원되는 key_shares(임시 ECDH 공개 키)를 포함한 ClientHello를 보내고, 서버는 ServerHello, 자체 key_share, 암호화된 확장, 인증서 및 완료 메시지를 모두 하나의 응답으로 보냅니다. 클라이언트는 완료 메시지를 보낸 직후 애플리케이션 데이터를 전송할 수 있습니다. TLS 1.2의 2-RTT 핸드셰이크와 비교하면 새 세션의 연결 설정 시간이 절반으로 줄어듭니다.

TLS 1.3의 키 도출

TLS 1.3은 구조화된 키 일정을 사용하는 HKDF(HMAC 기반 키 도출 함수)를 사용합니다. ECDHE 키 교환 후 공유 비밀은 다음 계층 구조에 입력됩니다. Extract(early_secret, DHE) -> handshake_secret, 그 다음 Extract(handshake_secret, 0) -> master_secret이 됩니다. 이를 바탕으로 HKDF-Expand-Label은 클라이언트와 서버의 핸드셰이크 트래픽, 애플리케이션 트래픽 및 재개를 위한 별도의 키를 도출합니다. 이러한 명확한 분리는 한 계층의 키가 손상되어도 다른 계층에 영향을 주지 않도록 하며, 이는 보다 임의적으로 PRF 기반 키를 도출하던 TLS 1.2에 비해 크게 개선된 점입니다.

세션 티켓과 PSK 재개

TLS 1.3 세션 재개는 이전 세션에서 도출한 사전 공유 키(PSK)를 사용합니다. 핸드셰이크가 완료되면 서버는 PSK 식별자와 티켓 값(재개 비밀을 담은 암호화된 데이터)을 포함하는 NewSessionTicket 메시지를 보냅니다. 다시 연결할 때 클라이언트는 ClientHello에 PSK 식별자를 포함합니다. 서버가 이를 인식하면 양쪽이 PSK와 새 ECDHE를 결합하여 새로운 세션 키를 도출하고, 순방향 비밀성을 유지하면서 1-RTT로 세션을 재개합니다. 티켓에는 설정 가능한 수명(일반적으로 24시간)이 있으며, 서버 측에서 순환하는 키로 암호화해야 합니다.

0-RTT 초기 데이터: 설계

TLS 1.3은 재개된 세션에서 0-RTT 초기 데이터를 허용합니다. 클라이언트는 이전 세션의 PSK를 사용하여 서버의 확인 응답이 오기 전에 첫 번째 전송으로 보내는 애플리케이션 데이터를 암호화합니다. 이를 통해 이전에 방문한 서버에 연결할 때 왕복을 한 번 줄여 반복 연결에서 거의 지연 시간이 없는 성능을 제공합니다. 서버는 early_data 확장과 max_early_data_size를 사용하여 NewSessionTicket에서 0-RTT 지원 여부를 알립니다. 서버에는 0-RTT 데이터를 수락하거나 거부하는 메커니즘이 있어야 하며, EncryptedExtensions에서 수락 여부를 알립니다.

0-RTT 재생 공격의 한계

0-RTT 데이터에는 근본적인 보안상의 한계가 있습니다. 바로 재생 공격에 취약하다는 점입니다. 경로상의 공격자가 첫 번째 전송을 가로채 서버로 재전송하면 서버가 초기 데이터를 다시 처리하게 됩니다. 이는 서버가 아직 어떤 메시지도 보내지 않았으므로 서버가 제공하는 최신성이 없기 때문에 피할 수 없는 문제입니다. 완화 방법은 다음과 같습니다. (1) 일회용 티켓: 서버가 처음 사용된 후 티켓을 무효화하며, memcached/Redis와 같은 분산 캐시를 사용할 수 있습니다. (2) 시간 제한 티켓: 짧은 시간 창 이후에는 0-RTT를 거부합니다(예: 5초). (3) 애플리케이션 수준의 멱등성: 안전한 GET과 동등한 작업에만 0-RTT를 허용합니다.

일회용 티켓을 사용한 재생 방지

가장 견고한 0-RTT 재생 방지 메커니즘은 일회용 세션 티켓입니다. 서버는 "사용된 티켓" 저장소를 유지하며, 여러 서버를 배포한 환경에서는 분산 캐시를 사용합니다. 0-RTT 데이터가 도착하면 서버는 해당 티켓을 이전에 본 적이 있는지 확인합니다. 이미 본 티켓이면 초기 데이터를 거부하고 1-RTT 방식으로 전환합니다. 처음 보는 티켓이면 사용된 것으로 표시한 후 초기 데이터를 처리합니다. 올바르게 동작하려면 클러스터의 모든 서버가 사용된 티켓 캐시를 공유해야 합니다. 티켓 수명과 일치하는 짧은 만료 시간을 Redis에 설정하는 방식이 일반적인 구현입니다. 이 메커니즘이 없으면 결제와 같은 비멱등 작업에 0-RTT를 사용하는 것은 안전하지 않습니다.

세션 재개에서의 순방향 비밀성

DHE를 사용하지 않는 TLS 1.3 PSK 재개는 재개된 세션에 순방향 비밀성을 제공하지 않습니다. PSK가 나중에 손상되면 재개된 세션의 모든 트래픽을 복호화할 수 있습니다. 순방향 비밀성을 유지하기 위해 TLS 1.3은 PSK-with-DHE를 지원합니다. ClientHello에는 PSK 식별자와 새 key_share가 모두 포함됩니다. 서버는 PSK와 ECDHE 결과를 결합하여 세션 키를 도출합니다. PSK가 손상되더라도 ECDHE 기여분 덕분에 과거 트래픽은 계속 보호됩니다. RFC 8446은 순방향 비밀성이 필요한 모든 재개 상황에서 PSK-with-DHE를 권장합니다.

TLS 1.3 암호 스위트 간소화

TLS 1.2에는 300개가 넘는 암호 스위트 조합이 있었으며, 그중 다수는 안전하지 않았습니다. TLS 1.3은 이를 AEAD를 사용하는 5개의 암호 스위트로 줄였습니다. TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 및 TLS_AES_128_CCM_8_SHA256입니다. 키 교환과 인증은 supported_groups 및 signature_algorithms 확장을 통해 별도로 협상됩니다. 이러한 분리는 TLS 1.2의 조합적 복잡성을 제거하고 모든 TLS 1.3 연결에서 인증된 암호화를 사용하도록 보장합니다.

HTTP/2와 HTTP/3의 초기 데이터

실제로 0-RTT는 클라이언트가 이전에 방문한 서버에 안전하고 멱등적인 GET 요청을 반복하는 HTTP/2 연결에서 가장 유용합니다. 브라우저는 0-RTT를 신중하게 구현합니다. Chrome은 안전한 HTTP 메서드에서 이를 활성화하지만 POST 요청은 0-RTT 데이터로 절대 전송하지 않습니다. QUIC을 통한 HTTP/3은 TLS 1.3을 기본적으로 통합하므로 QUIC의 0-RTT는 TLS 1.3의 메커니즘을 재사용합니다. QUIC에서는 0-RTT가 이전 세션의 전송 매개변수(흐름 제어, 스트림 제한)도 복원하므로 TLS 계층뿐 아니라 전체 연결 설정 비용을 더욱 줄입니다.

다운그레이드 방지

TLS 1.3에는 버전 다운그레이드 공격을 방지하는 메커니즘이 포함되어 있습니다. TLS 1.3이 협상되면 ServerHello의 난수 필드에 특정 표시 값이 들어갑니다. TLS 1.2로 대체되는 경우 마지막 8바이트가 고정된 값(0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01)으로 설정됩니다. TLS 1.3을 지원하는 클라이언트는 서버가 TLS 1.2를 협상할 때 이 표시 값을 확인하여 능동적인 다운그레이드 시도를 탐지합니다. 또한 완료 메시지에 사용되는 전사 해시는 버전 협상을 포함한 전체 핸드셰이크를 다루므로 변조를 탐지할 수 있습니다. TLS_FALLBACK_SCSV와 같은 SCSV(Signaling Cipher Suite Values)는 이전 TLS 버전을 위한 별도의 다운그레이드 신호를 제공합니다.

배포 시 고려 사항

TLS 1.3을 배포하려면 몇 가지 운영 세부 사항에 주의를 기울여야 합니다. 세션 티켓 암호화 키는 일반적으로 24시간마다 교체해야 하며, 모든 서버에서 재개할 수 있도록 서버 클러스터 전체에서 동기화해야 합니다. 불필요한 핸드셰이크 실패를 방지하려면 티켓 수명 동안 이전 티켓 복호화 키를 보관해야 합니다. OCSP 첨부는 인증서 상태를 확인하는 왕복을 한 번 줄여 주므로 TLS 1.3에서 더욱 중요합니다. 부하 분산기는 TLS 1.3 ClientHello를 수정하지 않고 전달해야 합니다. 일부 오래된 중간 장비가 알 수 없는 확장을 손상시키므로 호환성 모드가 필요한 경우가 있습니다.

0-RTT 재생 퀴즈

TLS 1.3에서 0-RTT 초기 데이터가 재생 공격에 취약한 이유는 무엇입니까?

TLS 1.3 재개 복습

TLS 1.3은 PSK 세션 티켓을 통해 1-RTT 전체 핸드셰이크와 0-RTT 재개를 구현합니다. 키 도출에는 각 트래픽 계층에 별도의 키를 생성하는 구조화된 일정을 사용하는 HKDF가 사용됩니다. 0-RTT 초기 데이터는 왕복을 한 번 줄여 주지만 재생 공격에 취약하며, 일회용 티켓을 사용하고 0-RTT를 멱등 작업으로 제한하여 완화할 수 있습니다. PSK-with-DHE는 재개 시 순방향 비밀성을 유지합니다. TLS 1.3은 암호 스위트를 5개의 AEAD 옵션으로 제한하여 오래되고 안전하지 않은 조합을 제거합니다. 다운그레이드 방지에는 서버 난수 필드의 특정 표시 값이 사용됩니다.

자주 묻는 질문

“TLS 1.3: 0-RTT, 조기 데이터 및 세션 재개” 강의는 무료인가요?

네 — “TLS 1.3: 0-RTT, 조기 데이터 및 세션 재개” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Cryptology Academy 강의 전체를 잠금 해제할 수 있습니다. Cryptology Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“TLS 1.3: 0-RTT, 조기 데이터 및 세션 재개”에서 뭘 배우나요?

TLS 1.3 세션 티켓, 0-RTT의 재생 공격 방지 한계, PSK 세션 재개 보안을 이해합니다. 브라우저에서 직접 실행하는 실습 코드로 Cryptology Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Cryptology Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Cryptology Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.

“TLS 1.3: 0-RTT, 조기 데이터 및 세션 재개” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Cryptology Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Cryptology Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. TLS 1.3: 0-RTT, 조기 데이터 및 세션 재개
  2. 상호 TLS (mTLS) 구현 패턴
  3. 모바일 및 데스크톱 애플리케이션의 인증서 고정
  4. TLS 성능: QUIC와 HTTP/3
← Cryptology Academy(으)로 돌아가기