TLS 연결이 한 번 더 왕복하는 이유: Cloudflare의 자동 키 교환

반응형

Cloudflare는 2026년 9월 8일 원본 서버와의 TLS 1. 3 핸드셰이크를 자동으로 최적화하는 Automatic Key Exchange를 공개했습니다.

핵심은 암호화 수준을 낮추는 것이 아니라, 원본 서버가 실제로 선호하고 지원하는 키 교환 방식을 미리 확인해 첫 시도부터 맞추는 것입니다. 이 글에서는 왜 TLS 연결이 불필요하게 한 번 더 왕복하는지, 그리고 포스트퀀텀 암호화 전환과 어떤 관계가 있는지 정리합니다.

3줄 핵심 요약

• TLS 1.3 연결에서 서버가 처음 제안받은 암호화 곡선을 지원하지 않으면 HelloRetryRequest가 발생해 왕복이 한 번 더 필요합니다.
• Cloudflare는 원본 서버를 미리 확인해 지원 가능한 키 교환 방식을 고르는 Automatic Key Exchange를 도입했고, 관찰 코호트의 재시도 비율을 52%에서 3.7%로 낮췄다고 밝혔습니다.
• 포스트퀀텀 하이브리드 방식도 지원하지만, 원본 서버가 지원하지 않는 상태에서 강제로 켜면 연결 실패가 날 수 있어 호환성 확인이 먼저입니다.

처음 제안이 틀리면 연결이 한 번 더 늦어진다

TLS 1. 3 클라이언트와 원본 서버가 키 교환 곡선을 협상할 때, Cloudflare가 모든 원본에 X25519를 먼저 추측하면 일부 서버는 다른 곡선만 지원할 수 있습니다.

이때 서버는 HelloRetryRequest를 보내고 클라이언트가 다시 제안해야 합니다. 연결 자체는 정상이어도 추가 왕복이 생기므로, 특히 지연 시간이 긴 사용자에게는 초기 응답이 늦어질 수 있습니다.

Automatic Key Exchange는 원본을 먼저 확인한다

Cloudflare는 원본 서버를 능동적으로 탐색해 실제로 성공하는 키 교환 방식을 확인하고, 이후 연결에서 그 선호 정보를 사용합니다. 포스트퀀텀 하이브리드 X25519MLKEM768을 지원하면 우선 선택하고, 지원하지 않으면 호환 가능한 고전적 곡선으로 연결합니다.

탐색은 매일 다시 수행되며, 트래픽을 조금씩 늘리는 방식으로 배포해 실패나 재시도 증가가 보이면 되돌릴 수 있게 했습니다.

Cloudflare가 공개한 관찰 결과

Cloudflare의 관찰 코호트에서는 HelloRetryRequest 비율이 약 52%에서 3. 7%로 낮아졌고, 스캔된 원본의 p90 핸드셰이크 지연이 150ms 이상 줄었다고 합니다.

같은 코호트에서 약 33%는 X25519MLKEM768을 선호했고, 64%는 X25519, 나머지는 다른 곡선을 선호했습니다. 포스트퀀텀 TLS 1.

3 연결의 99. 2%는 한 번의 왕복으로 완료됐으며, 포스트퀀텀 원본 트래픽은 하루 약 250억 건에서 450억 건으로 늘었다고 설명했습니다.

서비스 운영자가 확인할 설정과 주의점

기존·신규 도메인에서는 Automatic Key Exchange가 기본 활성화되며, Cloudflare 대시보드의 SSL/TLS > Overview > Configure에서 원본 연결과 포스트퀀텀 암호화 설정을 확인할 수 있습니다. 다만 규정 준수 설정으로 포스트퀀텀 하이브리드나 FIPS 곡선을 강제하기 전에 원본의 TLS 1.

3 구현이 해당 방식을 지원하는지 확인해야 합니다. 지원하지 않는 원본에 특정 곡선만 허용하면 TLS 1.

3 연결 전체가 실패할 수 있습니다.

이번 소식이 의미하는 것

포스트퀀텀 암호화는 알고리즘 하나를 바꾸는 작업만으로 끝나지 않습니다. 실제 원본 서버의 지원 여부를 측정하고, 실패율과 지연 시간을 보면서 점진적으로 적용해야 합니다.

다른 CDN이나 직접 TLS를 운영하는 팀도 ‘지원한다고 표시된가’보다 실제 핸드셰이크 성공률, HelloRetryRequest 비율, 지역별 p90 지연을 함께 모니터링하는 편이 안전합니다.

사용자와 업계에 미치는 영향

이번 접근은 보안 강도와 연결 성능을 동시에 조정해야 하는 운영 문제를 보여줍니다. 서비스 운영자는 포스트퀀텀 전환을 일괄 강제하기보다 원본별 호환성 데이터를 수집하고, 재시도율·핸드셰이크 지연·실패율을 기준으로 단계적으로 확대하는 것이 좋습니다.

확인할 점

수치와 개선 폭은 Cloudflare가 공개한 자체 스캔 및 연결 코호트 기준이며 모든 원본 서버와 사용자 환경에 그대로 적용된다고 단정할 수 없습니다. 능동 스캔 결과가 바뀌면 선택되는 곡선도 달라질 수 있습니다.

포스트퀀텀 또는 FIPS 설정을 강제하기 전에는 원본 TLS 라이브러리와 장비의 지원 범위를 별도로 검증해야 합니다.

출처

함께 읽을 글

• MFA를 했는데도 뚫리는 이유: 디바이스 코드 피싱 점검법
• Python으로 서버리스 앱을 만든다면? Cloudflare Workers GA에서 달라진 5가지
• AI 코딩 논쟁, 결론보다 중요한 실전 점검 5가지

• Cloudflare Blog — Automatic Key Exchange: faster, post-quantum secure origin handshakes

728x90