TLS 1.3은 “더 안전하면서 더 빠른” 웹을 목표로 설계됐습니다. 핵심은 핸드셰이크 왕복(RTT) 축소와 암호 스위트 단순화, 여기에 0-RTT(early data) 로 재방문 사용자의 체감 지연을 크게 줄이는 점이에요. 다만 0-RTT에는 재생 공격(replay) 같은 위험이 동반되므로, 안전한 범위를 정해 도입해야 합니다. 이 글은 TLS 1.3과 0-RTT를 구조적으로 이해하고, 운영에서 바로 쓰는 체크리스트까지 제공합니다.
1) TLS 1.3 한눈에 보기: 왜 기본이 빨라졌나
- 왕복 감소: TLS 1.2는 (대부분의 경우) 2-RTT가 필요했지만, TLS 1.3은 1-RTT로 암호화 채널을 완료합니다. 그만큼 TTFB가 줄어들고, 특히 모바일·해외 구간에서 이득이 큽니다.
- 암호 스위트 단순화: 취약하거나 오래된 알고리즘(예: RSA 키교환, CBC, RC4 등) 제거. 기본은 (EC)DHE+AEAD 조합으로 전방기밀성(PFS) 을 보장합니다.
- 성능 친화적 스위트: 서버는 보통 AES-GCM과 ChaCha20-Poly1305 둘 다 제공해, 클라이언트·CPU 특성에 맞게 자동 선택하도록 합니다.
핵심 키워드: TLS 1.3, 핸드셰이크, 레이턴시, 보안 강화, 전방기밀성.
2) 0-RTT(early data): 재방문은 “거의 즉시” 요청
0-RTT는 이전에 세션 재개(PSK/세션 티켓) 를 맺은 클라이언트가 핸드셰이크와 동시에 애플리케이션 데이터를 전송하는 기능입니다. 즉, 재방문 사용자는 추가 왕복 없이 첫 요청이 나갑니다.
체감 이득이 큰 경우
- 짧은 API 호출(권한 확인, 피드 헤더 등)
- 이미지·정적 리소스의 캐시 미스 응답
- 모바일 재연결(앱 복귀·백그라운드 이후 첫 요청)
중요: 0-RTT 데이터는 완전한 PFS가 적용되지 않고, 재생 공격에 취약할 수 있습니다. 그래서 “무조건 켜기”가 아니라 안전한 범위를 정해 선별 허용해야 합니다.
3) 보안 유지하면서 0-RTT 쓰는 법(안전 가이드)
원칙 1: 아이템포턴트만 허용
- GET, HEAD 등 서버 상태를 바꾸지 않는 요청만 0-RTT 허용.
- POST/PUT/PATCH/DELETE 등 상태 변경은 1-RTT로 강제.
원칙 2: 재생 방지(anti-replay) 적용
- 세션 티켓 + 클라이언트 헬로 토큰에 대해 짧은 수명/캐시 운영.
- 서버·프록시 전역의 재생 캐시(예: ticket + client nonce 키)를 두고, 같은 매개변수의 재도착을 차단.
- 지리 분산(멀티 리전) 환경에선 분산 캐시/대역 제한으로 창구를 좁혀 운영.
원칙 3: 민감한 엔드포인트 차단
- 로그인, 결제, 비밀번호 변경, 쿠폰·포인트 차감 등은 0-RTT 금지 목록에 고정.
- 토큰 발급(OAuth/OIDC) 등 재생 위험이 있는 요청도 금지.
원칙 4: 정책 가시화
- 서버는 Early-Data 헤더를 읽어 0-RTT 여부를 판단하고, 필요하면 425 Too Early로 재시도 유도(1-RTT로 다시 오도록).
- 관측 시스템에서 0-RTT 비율, 425 비율, 재시도 성공률을 별도로 추적.
4) 서버·프록시 설정 체크리스트(실무)
- 스택 버전
- OpenSSL 1.1.1+/BoringSSL/wolfSSL 등 TLS 1.3 지원 스택 확인.
- NGINX(메인라인), Envoy, HAProxy, Apache에서 TLSv1.3 on 및 선호 스위트 설정.
- 암호 스위트
- TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 조합을 우선 제공.
- 모바일 비중이 높다면 ChaCha20 가용성 확보.
- 0-RTT 활성화(선택)
- 세션 티켓 발급(new_session_tickets) 수와 유효기간을 짧게.
- anti-replay 캐시 구성(메모리/외부 캐시)과 금지 라우트(와일드카드·정확 매칭) 정의.
- L7 프록시·CDN과 정책 동기화: 프록시가 Early-Data를 존중하도록.
- 인증서·체인 최적화
- OCSP 스테이플링과 중간 인증서 캐시로 첫 연결 지연 최소화.
- ALPN으로 h2/h3 광고(HTTP/2·HTTP/3 병행) → 핸드셰이크 후 프로토콜 선택이 즉시 이뤄짐.
- 모니터링 지표
- TLS 레벨: 핸드셰이크 시간, 0-RTT 비율, 425 응답률, 티켓 재사용률.
- UX 레벨: TTFB, LCP, 오류율(특히 모바일·해외 세그먼트) 분리 관측.
5) 성능 효과를 숫자로 검증하는 방법(AB 테스트)
- 대상 구간: 재방문 비율이 높고 RTT가 큰 국가·이동통신사·앱 사용 시나리오.
- 방법: 전체의 10~30% 그룹에 TLS 1.3 + 0-RTT를 열고, 대조군은 TLS 1.3만 사용.
- 평가: TTFB p50/p90, API 지연 p95, 425 응답 후 재시도 성공률, 오류율 변화.
- 해석 포인트: p90/p99 꼬리 분포가 줄어드는지, 0-RTT로 첫 화면 시각 요소(폰트, 프레임 데이터)가 더 빨라졌는지 확인.
6) 자주 묻는 질문(FAQ)
Q. 0-RTT는 항상 안전한가요?
A. 아닙니다. 재생 공격에 취약할 수 있어 아이템포턴트 요청만 허용하고, anti-replay를 반드시 구성해야 합니다.
Q. TLS 1.3만 켜도 빨라지나요?
A. 대체로 핸드셰이크 지연이 즉시 줄고, 안전한 스위트로 정리돼 이점이 큽니다. 다만 인증서 체인/OCSP/네트워크 병목이 남아 있으면 체감이 제한됩니다.
Q. HTTP/3와 관계는?
A. HTTP/3는 QUIC 위에서 TLS 1.3 보안 속성을 사용합니다. 모바일·손실 환경에선 HTTP/3 + TLS 1.3 조합이 체감상 더 유리한 경우가 많습니다.
Q. 캐시나 CDN과 충돌 없나요?
A. 0-RTT는 전송 초기화를 빠르게 할 뿐, 캐시 정책은 그대로 적용됩니다. 다만 CDN·프록시가 Early-Data/425를 올바로 처리하도록 설정해야 합니다.
7) 도입 로드맵(요약)
- TLS 1.3 활성화 → 2) 인증서/체인/OCSP 최적화 → 3) 세션 티켓·PSK 파라미터 점검 → 4) 0-RTT는 안전 구간만 허용(아이템포턴트+anti-replay) → 5) 모바일·해외 AB 테스트 → 6) 지표 기반 확대 적용.
마무리
TLS 1.3은 보안과 성능을 동시에 끌어올리는 표준입니다. 여기에 0-RTT를 선별적으로 더하면 재방문·앱 복귀 시나리오에서 핸드셰이크 지연을 사실상 제거할 수 있어요. 다만 보안 경계를 분명히 두고, 지표로 검증하면서 단계적 확대가 정답입니다.