클라우드플레어 AKE 공개 — 오리진 핸드셰이크 재시도 52%에서 3.7%로, 지연 150ms 단축 | 뉴스

클라우드플레어가 오리진 서버와의 TLS 1.3 연결에서 키 교환 알고리즘을 자동으로 고르는 AKE(Automatic Key Exchange)를 공개했다. 오리진을 미리 프로브해 지원 알고리즘을 파악한 뒤, 하이브리드 포스트양자 알고리즘 X25519MLKEM768을 우선 시도하고 안 되면 고전 알고리즘으로 내려간다.

효과는 숫자로 나왔다. 스캔한 오리진 기준 HelloRetryRequest가 필요한 연결 비율이 약 52%에서 3.7%로 떨어졌고, 90퍼센타일 핸드셰이크 지연이 150밀리초 넘게 줄었다. 보호되는 트래픽은 하루 약 450억 연결 규모다.

TLS 핸드셰이크의 왕복 한 번은 평소엔 별것 아닌 것처럼 보인다. 하지만 엣지와 오리진 사이 RTT가 150ms인 국제 구간에서는 이야기가 다르다. 연결마다 왕복이 한 번 더 붙으면 첫 바이트까지의 시간이 그대로 늘고, 커넥션 풀이 얇은 시간대엔 사용자 체감으로 직결된다. 이번 발표는 그 왕복 하나를 구조적으로 없앤 사례다.

HelloRetryRequest가 왜 생기나

TLS 1.3 클라이언트는 ClientHello를 보낼 때 "아마 이걸 쓰겠지" 하고 키 공유(key share)를 추측해서 미리 넣는다. 서버가 그 알고리즘을 지원하면 한 번의 왕복으로 끝난다. 추측이 빗나가면 서버는 HelloRetryRequest를 보내 "다른 걸로 다시 보내라"고 요구하고, 클라이언트는 새 키 공유로 ClientHello를 한 번 더 보낸다. 왕복 하나가 추가된다.

# 정상 (추측 적중)
Client --ClientHello(key_share: X25519MLKEM768)--> Server
Client <--------ServerHello + Finished------------ Server   # 1-RTT

# 빗나감 (HRR 발생)
Client --ClientHello(key_share: X25519MLKEM768)--> Server
Client <--------HelloRetryRequest------------------ Server   # "그거 말고 X25519"
Client --ClientHello(key_share: X25519)----------> Server
Client <--------ServerHello + Finished------------ Server   # 2-RTT

포스트양자 전환기에 이 추측은 특히 잘 빗나간다. 하이브리드 알고리즘을 지원하는 쪽과 아직 고전 곡선만 지원하는 쪽이 섞여 있기 때문이다. 앞서 나가면 재시도가 늘고, 보수적으로 가면 포스트양자 보호를 못 받는다.

AKE가 푸는 방식 — 추측 대신 관측

52% → 3.7%

HelloRetryRequest 발생 비율

150ms+

p90 핸드셰이크 지연 감소

450억/일

포스트양자 키 교환으로 보호되는 연결

33% / 64%

X25519MLKEM768 / X25519 배정 비율

AKE는 오리진마다 어떤 알고리즘을 실제로 받아 주는지 미리 탐지해 기록해 두고, 다음 연결부터는 그 결과대로 키 공유를 구성한다. 스캔 결과 약 33%의 오리진이 X25519MLKEM768로 배정됐고, 64%는 X25519에 머물렀으며 나머지는 오리진이 지원하는 다른 고전 곡선으로 배정됐다. 포스트양자 오리진 트래픽은 롤아웃 기간에 하루 약 250억 연결에서 450억 연결로 늘었다.

핵심 아이디어 클라이언트의 "추측"을 서버 지식으로 대체한 것뿐이다. 새로운 암호학이 아니라 운영 데이터를 핸드셰이크 결정에 주입한 사례이고, 그래서 재현 가능하다. 사내에서 다수 백엔드에 TLS를 맺는 프록시를 운영한다면 같은 전략을 쓸 수 있다.

내 서버는 지금 어느 쪽인가

확인은 간단하다. OpenSSL 3.5 이상이면 -groups로 하이브리드 그룹을 지정해 핸드셰이크를 시도해 보면 된다. 재시도가 뜨는지, 어떤 그룹으로 합의됐는지가 바로 보인다.

# 하이브리드 PQ 지원 여부 확인 (OpenSSL 3.5+)
openssl s_client -connect example.com:443 \
  -groups X25519MLKEM768 -tls1_3 </dev/null 2>&1 | grep -iE "negotiated|group"

# HRR이 실제로 발생하는지 보려면 핸드셰이크 메시지를 추적
openssl s_client -connect example.com:443 -trace </dev/null 2>&1 | grep -i "hello_retry"

# nginx 1.27+ 예시: 선호 그룹 순서 지정
# ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

오리진 운영자 체크리스트

✓OpenSSL/BoringSSL 버전이 하이브리드 그룹을 지원하는지 확인 (3.5 계열 이상 권장)

✓선호 그룹 목록에 X25519MLKEM768을 앞에 두되 고전 곡선 폴백을 남길 것

✓하이브리드 키 공유로 ClientHello가 커지면서 일부 미들박스가 조각화된 첫 패킷을 흘리는 사례가 있으니 실제 경로에서 검증

✓핸드셰이크 지연을 p50이 아니라 p90·p99로 모니터링 — HRR은 꼬리 지연으로 나타난다

✓HSM·TLS 종단 장비를 쓰면 펌웨어 지원 여부를 벤더에 확인

지금 이걸 신경 써야 하는 이유

"양자 컴퓨터는 아직 멀었다"는 반론은 절반만 맞다. 문제는 지금 수집해 두고 나중에 해독한다(harvest now, decrypt later)는 공격 모델이다. 오늘 암호화된 트래픽이 10년 뒤 풀린다면, 장기 기밀성이 필요한 데이터는 지금 키 교환을 바꿔야 한다. 반대로 세션 인증서·서명 알고리즘까지 서둘러 바꿀 필요는 없다. 서명은 공격 시점에 위조가 필요하지만, 키 교환은 지금의 기록이 미래에 풀리기 때문이다.

출처

Cloudflare Blog, "Automatic Key Exchange: faster, post-quantum secure origin handshakes" — https://blog.cloudflare.com/automatic-key-exchange-for-origins/
SDxCentral, "Cloudflare: 45 billion daily connections see automated post-quantum key exchange" — https://www.sdxcentral.com/news/cloudflare-45-billion-daily-connections-see-automated-post-quantum-key-exchange/
ChannelE2E, "Cloudflare prepares billions of daily connections for post-quantum era" — https://www.channele2e.com/news/cloudflare-enhances-security-with-automatic-post-quantum-key-exchange

자주 묻는 질문

HelloRetryRequest가 뭔가요?

TLS 1.3에서 클라이언트가 미리 보낸 키 공유 알고리즘을 서버가 지원하지 않을 때, 서버가 다른 알고리즘으로 다시 보내라고 요구하는 메시지입니다. 이때 핸드셰이크 왕복이 한 번 더 발생해 연결 수립이 1-RTT에서 2-RTT로 늘어납니다.

AKE는 새로운 암호 알고리즘인가요?

아닙니다. 기존 TLS 1.3 위에서 어떤 키 교환 그룹을 쓸지 자동으로 고르는 운영 기법입니다. 오리진을 미리 탐지해 지원 알고리즘을 파악하고, 하이브리드 포스트양자 알고리즘을 우선 시도한 뒤 필요하면 고전 알고리즘으로 폴백합니다.

X25519MLKEM768이 무엇인가요?

고전 곡선 X25519와 격자 기반 ML-KEM-768을 결합한 하이브리드 키 교환 방식입니다. 둘 중 하나가 깨져도 다른 하나가 남도록 설계돼 있어, 포스트양자 전환기의 사실상 표준 선택지로 자리 잡았습니다.

우리 서버도 지금 포스트양자 키 교환을 켜야 하나요?

장기 기밀성이 필요한 트래픽이 있다면 지금이 맞습니다. 지금 수집해 두고 나중에 해독하는 공격 모델 때문입니다. 다만 그룹 목록에 고전 곡선 폴백을 남기고, 하이브리드로 커진 ClientHello가 경로상 장비에서 문제를 일으키지 않는지 실제 경로에서 검증해야 합니다.

핸드셰이크 지연은 어떤 지표로 봐야 하나요?

평균이나 p50이 아니라 p90·p99를 봐야 합니다. 재시도는 전체 연결 중 일부에서만 발생하므로 평균에는 잘 드러나지 않고 꼬리 지연에 몰립니다. 이번 사례에서도 개선 폭이 p90 기준으로 제시됐습니다.