TLS 1.3 표준의 탄생 배경과 기존 프로토콜의 한계

전송 계층 보안(TLS, Transport Layer Security)은 인터넷 웹 보안의 핵심 기틀을 형성하는 암호화 통신 규약입니다. 그러나 과거 수십 년 동안 널리 사용되었던 TLS 1.2 이하 버전들은 프로토콜 설계 구조상 적지 않은 성능 지연과 보안적 취약점을 안고 있었습니다. TLS 1.2의 핸드셰이크 왕복 수는 전체 연결인지 세션 재개인지 등 협상 흐름에 따라 달라집니다. 이는 물리적 거리가 먼 글로벌 네트워크나 고지연 모바일 환경에서 웹페이지 로딩 속도와 API 응답성을 심각하게 저하시키는 주요 병목으로 작용했습니다.

또한 TLS 1.2 이전 버전은 하위 호환성을 이유로 정적 RSA 키 교환, CBC 모드 암호화, SHA-1 해시 함수 등 암호학적으로 취약한 알고리즘들을 폭넓게 허용했습니다. 특히 정적 RSA 키 교환 방식은 서버의 개인키가 사후에 유출될 경우 과거에 감청하여 저장해 둔 모든 암호화 트래픽이 일괄 복호화될 수 있는 치명적인 약점을 내포하고 있었습니다. 이에 IETF는 2018년 8월, 연결 수립 속도를 획기적으로 개선하고 보안 결함을 근본적으로 걷어낸 완전한 개정판인 RFC 8446(TLS 1.3)을 공식 표준으로 비준했습니다.

1-RTT/0-RTT 핸드셰이크 구조와 전방향 보안(Forward Secrecy)

TLS 1.3의 인증서 기반 전체 핸드셰이크는 보통 1-RTT입니다. 클라이언트는 ClientHello에 키 공유 제안을 넣고 서버는 ServerHello에서 선택된 키 공유를 답합니다. 제안된 그룹을 서버가 받아들일 수 없어 HelloRetryRequest를 보내면 왕복이 추가될 수 있으므로, 1-RTT는 모든 연결의 보장값이 아니라 일반 경로의 설명입니다. 세션 재개는 PSK 기반 1-RTT로도 가능하며, 별도 선택 사항인 0-RTT에서는 클라이언트가 첫 비행에 조기 데이터를 보낼 수 있습니다. RFC 8446 §§2.3, 4.1.4

0-RTT가 절약하는 것은 조기 데이터를 보내기 전에 핸드셰이크 왕복이 끝나기를 기다리는 시간입니다. 네트워크 전파 지연이나 전체 핸드셰이크 완료가 사라지는 것은 아니며, 서버가 조기 데이터를 거부하면 1-RTT로 이어질 수 있습니다. 체감 효과는 세션 재개 성공, 서버의 조기 데이터 수락, 경로와 애플리케이션 처리에 따라 달라집니다. RFC 8446 §2.3

TLS 1.3은 정적 RSA 키 교환을 제거했지만, 모든 연결이 같은 전방향 보안을 갖는다는 뜻은 아닙니다. 인증서 기반 (EC)DHE와 PSK+(EC)DHE는 새 키 공유를 사용합니다. 반면 PSK 단독(psk_ke)에는 새 (EC)DHE 교환이 없고, RFC는 0-RTT 조기 데이터에 완전한 전방향 보안이 없다고 명시합니다. 따라서 “TLS 1.3이면 전방향 보안이 필수”라고 일반화하지 말고 협상된 모드와 데이터 종류를 확인해야 합니다. RFC 8446 §§4.2.9, E.1.3

실무 웹 인프라 적용과 설정 가이드

엔터프라이즈 인프라에서 TLS 1.3을 활성화하는 것은 웹 서버(Nginx, Apache, Caddy)나 클라우드 CDN(Cloudflare, AWS CloudFront)의 구성 옵션을 업데이트함으로써 비교적 간단히 적용할 수 있습니다. 예를 들어 Nginx 환경에서는 ssl_protocols 지시어에 TLSv1.3을 포함하고, 현대적인 AEAD(Authenticated Encryption with Associated Data) 전용 암호화 스위트인 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 등을 명시적으로 지정합니다.

TLS 1.3을 지원하도록 설정해도 모든 요청의 왕복 시간이나 웹 성능 지표가 일정 비율로 개선되는 것은 아닙니다. 재개된 연결에서 0-RTT가 수락되면 일부 요청 데이터를 핸드셰이크 완료 전에 보낼 수 있지만, 효과는 연결 재사용률·조기 데이터 수락률·경로 지연·애플리케이션 처리에 따라 달라집니다. 도입 전후 같은 사용자군과 요청 경로를 비교하고, 핸드셰이크 재개 및 조기 데이터 수락 여부와 실제 사용자 성능 지표를 따로 관찰하세요.

0-RTT의 보안 경계와 엔드포인트별 판단

TLS 1.3의 인증서 기반 전체 핸드셰이크는 보통 1-RTT지만, HelloRetryRequest가 있으면 추가 왕복이 발생할 수 있습니다. TLS 1.2도 전체 핸드셰이크와 세션 재개에 따라 RTT가 달라지므로 버전만으로 2-RTT라고 단정하지 마세요. TLS 1.3 PSK 재개는 1-RTT로 가능하고, 0-RTT는 첫 비행에 조기 데이터를 함께 보내는 선택 사항입니다.

PSK 단독 키 설정(psk_ke)에는 새 (EC)DHE 공유가 없지만 psk_dhe_ke는 PSK와 (EC)DHE를 결합합니다. 따라서 모든 TLS 1.3 세션이 같은 전방향 보안 특성을 갖는다고 말할 수 없습니다. RFC 8446은 특히 0-RTT 데이터에 전방향 보안과 연결 간 재생 방지 보장이 없다고 명시합니다.

조기 데이터는 같은 연결 안에서 이중 처리되지 않더라도 별도 연결에서 재생될 수 있습니다. RFC §8의 서버 측 완화책도 구성·상태 공유의 제약이 있으며, TLS 계층이 애플리케이션에 완전한 중복 방지를 보장하지 않습니다. 따라서 HTTP 메서드 이름만으로 허용 여부를 정하지 마세요. 예를 들어 결제를 발생시키는 GET /account/charge는 GET이어도 0-RTT에 부적합합니다. 외부 효과가 없고 중복 수신을 견딜 수 있는 경로만 후보로 두고, 결제·예약 생성·상태 변경은 핸드셰이크 후 처리하세요. 변경 작업의 중복 방지는 요청 식별자를 상태 변경과 원자적으로 기록하는 애플리케이션 멱등성 설계로 보완할 수 있습니다.

도입 전에는 (1) 어느 TLS 종단점이 early data를 받는지, (2) 허용 경로의 실제 부작용, (3) 서버·리전 간 티켓/재생 상태 공유, (4) 0-RTT 거부 시 1-RTT fallback을 확인하세요. 이는 점검 예시이며 서버나 CDN에서 실행한 결과가 아닙니다. RFC 8446 §§2.2–2.3, 4.2.9, 8을 참조하세요.