TLS 1.3 사전 공유 키(PSK)와 티켓 기반 세션 재개 아키텍처
TLS 1.3에서 이전 연결에서 얻은 PSK를 이용해 세션을 재개하는 방식과 티켓의 역할을 설명합니다. 선택 사항인 0-RTT 조기 데이터는 재전송될 수 있으므로, 중복 실행의 영향과 애플리케이션별 대응을 함께 살펴봅니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
TLS 연결 설정의 왕복 횟수와 암호 연산은 프로토콜 버전, 키 교환 방식, 재개 여부, 네트워크 조건에 따라 달라집니다. 따라서 모든 전체 핸드셰이크가 반드시 1~2 RTT를 쓰거나 TTFB를 악화시킨다고 일반화할 수 없습니다. TLS 세션 재개는 이전 연결에서 얻은 PSK를 사용해 후속 핸드셰이크를 줄일 수 있으며, 0-RTT 조기 데이터는 선택 기능으로 재전송 위험을 별도로 평가해야 합니다.
1. TLS 1.3 사전 공유 키(PSK)와 NewSessionTicket 암호 구조
TLS 1.3은 재개에 PSK(사전 공유 키)를 사용할 수 있습니다. 이전 핸드셰이크가 끝난 뒤 서버는 NewSessionTicket을 보내고, 클라이언트와 서버는 이 티켓을 후속 연결에서 사용할 재개 정보로 다룹니다. RFC 8446은 PSK를 ClientHello에서 identity와 binder로 제시하고 서버가 이를 수락하는 절차를 규정합니다. 티켓 내부 형식과 서버의 키 보관 방식은 구현에 따라 달라질 수 있으므로 모든 서버가 동일한 암호화 blob이나 특정 ticket encryption key 구조를 쓴다고 단정할 수 없습니다.
2. 0-RTT 조기 데이터와 재전송 위험
TLS 1.3은 이전 세션에서 유도한 PSK로 핸드셰이크 완료 전 조기 데이터를 보낼 수 있지만, 세션 재개 자체가 0-RTT를 요구하지는 않습니다. 재개된 PSK 연결도 핸드셰이크 뒤에 데이터를 보낼 수 있습니다. RFC 8446은 0-RTT가 재전송될 수 있고 순방향 비밀성을 제공하지 않는다고 설명하므로, 상태 변경이나 중복 실행 피해가 있는 작업은 조기 데이터에 보내지 말고 TLS 계층이 중복 처리를 막는다고 가정하지 마세요. 또한 PSK-only와 (EC)DHE를 결합한 PSK 교환은 순방향 비밀성 특성이 다릅니다. 재개가 모든 공개키 계산이나 인증 확인을 없앤다고 단정할 수 없습니다.
Cloudflare의 TLS 1.3 해설은 세션 티켓 기반 서버가 앞서 처리한 0-RTT 요청인지 항상 알 수 없다는 재전송 사례를 설명하며, 상태 변경을 일으키지 않는 작업만 처리하도록 권합니다. RFC 8446도 애플리케이션 프로토콜이 재전송에 안전한지 평가하고, 적절한 프로파일 없이 0-RTT를 사용하지 말라고 규정합니다. 모든 GET이 자동으로 안전하다고 단정하지 말고, 실제 라우트의 부작용·중복 실행 허용성·서버 간 재생 방지를 확인하세요. 위험을 평가하기 어렵다면 해당 경로에서는 조기 데이터를 끄고 핸드셰이크 뒤 처리합니다.
RFC 8446은 서버가 0-RTT를 수락할 때 버전, 암호 스위트, ALPN 등 선택된 PSK에 연결된 협상값을 확인하도록 요구합니다. 서버가 조기 데이터를 받더라도 애플리케이션은 재전송 가능성을 별도로 다뤄야 합니다. 요청 식별자를 이용한 중복 제거처럼 애플리케이션 상태에 맞는 보호를 설계하고, 보호가 불가능한 작업은 재개 후 1-RTT 경로에서 처리하세요.
3. 조기 데이터는 작업별로 검토
운영 검토에서는 세션 재개와 0-RTT 허용 여부를 별도 항목으로 기록하고, 전체 핸드셰이크와 재개 핸드셰이크의 지연·계산량을 같은 조건에서 비교하세요. 티켓 발급과 PSK 선택이 기대대로 동작하는지 관찰하되, 구현체별 티켓 키 관리 방식은 TLS 사양만으로 추정하지 마세요. 성능 측정만으로 재전송 안전성이 확인되지는 않습니다.