Session Resumption은 클라이언트와 서버가 이전에 체결한 보안 세션의 일부 정보를 재사용하여 전체 핸드셰이크를 다시 수행하지 않고도 빠르게 안전한 연결을 복원하는 기술입니다. 주로 TLS/SSL 같은 보안 프로토콜에서 사용되며, 지연(latency)과 서버 부하를 줄이고 배터리·CPU 사용을 절감하는 목적이 있습니다. 주요 방식 - TLS 1.2 이전 방식 - 세션 ID: 서버가 세션 상태(대칭 키, 암호 매개변수 등)를 서버 메모리에 저장하고, 클라이언트가 이후 연결 시 세션 ID를 제시하면 서버가 해당 상태를 찾아 재사용. - 세션 티켓(RFC 5077): 서버가 세션 상태를 암호화해 "티켓"으로 클라이언트에 주고, 클라이언트가 다음 연결에서 티켓을 보내면 서버가 복호화해 상태를 복원(서버는 상태를 유지하지 않아도 됨 → stateless). - TLS 1.3 방식 - PSK(Pre-Shared Key) 기반 재개: 이전 핸드셰이크에서 파생된 PSK(티켓 형태로 전달)를 사용해 빠른(1-RTT 또는 0-RTT) 핸드셰이크를 수행. - 0-RTT(early data): 클라이언트가 최초 패킷에 애플리케이션 데이터를 담아 보낼 수 있어 지연을 더 줄임. 그러나 재전송(replay) 공격 위험이 있어 서버가 허용하는 데이터 범위(주로 멱등 요청)에 제한을 두어야 함. - PSK + (EC)DHE 결합: 필요 시 PSK와 새로운 임시 키 교환을 결합해 재개 시에도 재생성된 비밀을 통해 완전한 전향 비밀성(forward secrecy)을 확보할 수 있음. 이점 - 핸드셰이크에 필요한 왕복(round-trip) 감소 → 지연 시간 단축 - 서버의 연산(특히 공개키 연산) 부담 경감 → CPU 사용량 감소 - 연결 빈도가 높은 환경(웹 브라우저, 모바일 앱, API 게이트웨이 등)에서 효율성 향상 보안 고려사항 - 티켓/PSK 수명: 너무 길면 도난 시 장기간 위험, 너무 짧으면 이점 감소. 적절한 만료와 회전 필요. - 티켓 키 관리: 서버가 티켓을 암복호화하는 키를 안전하게 보관하고 주기적으로 롤링(교체)해야 함. 키 유출 시 모든 티켓이 위험해짐. - 0-RTT 재생 공격: 0-RTT로 받은 데이터는 재생될 수 있으므로 서버는 이를 허용할 때 재생 방지 대책이나 idempotent한 요청만 처리하도록 제한해야 함. - 전향 비밀성: 일부 재개 방식은 원래 세션의 비밀에 의존하므로, 티켓/PSK의 노출 시 과거 세션 복구 위험이 발생. TLS 1.3은 PSK+(EC)DHE로 이를 보완 가능. - 클라이언트 측 보안: 클라이언트가 티켓을 안전히 보관(예: 암호화된 저장소)해야 함. 동작 예시(요약) - 세션 티켓 방식(TLS 1.2) 1. 초기 핸드셰이크 완료 → 서버가 세션 상태를 암호화해 티켓으로 클라이언트에 송신. 2. 클라이언트가 재접속 시 티켓을 서버에 전송. 3. 서버가 티켓을 복호화해 세션 상태 복원 → 전체 핸드셰이크를 건너뜀. - TLS 1.3 PSK / 0-RTT 1. 초기 연결에서 서버가 재개용 티켓(PSK) 발급. 2. 클라이언트가 다음 연결에서 티켓을 사용해 빠른 재개를 시도(옵션으로 0-RTT 데이터를 포함). 3. 서버가 PSK를 검증하고 필요한 경우 추가 키 교환을 수행해 보안 세션을 복원. 요약 Session Resumption은 이미 합의된 보안 매개변수를 재사용해 핸드셰이크 비용과 지연을 줄이는 기술로, 구현 방식(TLS 버전 및 세션 ID, 티켓, PSK/0-RTT 등)에 따라 성능과 보안 특성이 다릅니다. 티켓 만료·키 관리·0-RTT 재생 방지 같은 운영·보안 대책을 적절히 설계해야 안전하게 이점을 누릴 수 있습니다.
