Cloudflare, 오리진 TLS 핸드셰이크 재시도율을 52%에서 3.7%로 — 자동 키 교환(AKE) 도입

본문

Cloudflare는 리버스 프록시로 동작하기 때문에 방문자와의 연결과 오리진 서버와의 연결, 두 개의 독립적인 TLS 연결을 유지합니다. 문제는 두 번째 연결, 즉 Cloudflare가 TLS 클라이언트로서 오리진에 접속할 때 발생합니다. TLS 1.3은 첫 패킷인 ClientHello에 키 합의(key agreement) 알고리즘용 클라이언트 키쉐어를 미리 실어 보내야 하는데, 오리진이 무엇을 지원하는지 아직 알 수 없어 사실상 '추측'이 필요합니다. 추측이 맞으면 1-RTT로 핸드셰이크가 끝나지만, 틀리면 오리진이 HelloRetryRequest(HRR)를 보내 다시 시작해야 하므로 왕복 한 번이 통째로 추가됩니다.

정적 추측의 비용 — X25519와 post-quantum의 딜레마

그동안 Cloudflare는 모든 오리진에 대해 X25519를 고정으로 첫 키쉐어로 보냈습니다. 95% 이상의 오리진이 지원하므로 안전한 선택이었지만 두 가지 낭비가 있었습니다. 첫째, X25519는 양자 컴퓨터에 취약합니다. Cloudflare는 2023년 9월부터 post-quantum 하이브리드 알고리즘(X25519Kyber768Draft00, 현재는 표준화된 X25519MLKEM768) 지원을 오리진에 '광고'해 왔지만, 이를 첫 키쉐어로 보내지는 못했습니다. X25519MLKEM768 키쉐어는 1,216바이트로 X25519의 32바이트보다 훨씬 커서 ClientHello가 여러 패킷으로 쪼개지는데, 과거 조사에서 약 0.34%의 오리진이 분할된 ClientHello를 처리하지 못해 핸드셰이크가 실패했습니다. 그래서 post-quantum 가능 오리진도 HRR로 업그레이드해야 했고, 사실상 모든 post-quantum 핸드셰이크가 2-RTT를 강제로 지불했습니다. 둘째, 오리진의 6% 이상이 X25519보다 P-256이나 P-384를 선호해 순수 클래식 연결에서조차 HRR이 발생했습니다. 또한 최신 OpenSSL·BoringSSL·rustls 빌드는 클래식 키쉐어를 받으면 post-quantum을 우선하기 위해 즉시 HRR을 보내는 경우가 많아 불필요한 재시도가 더 늘었습니다.

Automatic Key Exchange의 동작 방식

Automatic Key Exchange(AKE)는 기존 Automatic SSL/TLS의 스캐닝 파이프라인을 재활용해 추측을 측정으로 바꿉니다. TLS 1.3 가능 오리진마다 프로덕션 트래픽 경로 밖에서 가벼운 TLS 핸드셰이크를 여러 번 수행하며, 각각 X25519, P-256, P-384, P-521, X25519MLKEM768 중 정확히 하나의 그룹만 제시해 지원 집합 전체를 파악합니다. 하나의 도메인이 여러 서브도메인·오리진을 앞세우는 경우 각각을 독립 평가하되 실제 트래픽 양으로 가중치를 둬, 잠자는 서브도메인과 트래픽이 몰리는 엔드포인트를 동일하게 취급하지 않습니다. 이후 post-quantum 하이브리드(X25519MLKEM768)를 최우선으로 하고, 불가하면 오리진이 받아들이는 가장 빠른 클래식 알고리즘을 선택합니다. 새 선호도는 해당 오리진 트래픽의 소량에 먼저 적용되고 실패율과 HRR율을 감시하며, 기준선을 넘으면 자동 롤백됩니다. 오리진 구성은 계속 바뀌므로 매일 재스캔합니다. 대부분의 고객은 설정할 것이 없고, 필요하면 대시보드의 SSL/TLS > Overview > Configure에서 끌 수 있습니다.

새로 추가된 Compliance requirements 설정으로 협상 가능한 키 합의를 post-quantum 하이브리드 전용 또는 FIPS 준수 알고리즘 전용으로 제한할 수도 있습니다. 다만 이는 Cloudflare가 협상할 수 있는 범위를 좁힐 뿐 오리진에 새로운 암호 능력을 부여하지 않으므로, X25519MLKEM768을 지원하지 않는 오리진에 post-quantum을 강제하면 모든 TLS 1.3 연결이 실패합니다. Cloudflare는 엄격한 정책 의무가 없다면 둘 다 선택하지 말 것을 권합니다.

결과 수치

스캔이 끝난 초기 코호트에서 약 64%는 기존 X25519 선호를 유지해 변화가 없었고, 약 33%가 X25519MLKEM768 선호로 전환돼 1-RTT로 harvest-now, decrypt-later 공격 방어를 얻었습니다. 나머지 3%는 P-384 등 오리진이 선호하는 다른 클래식 곡선을 선택했습니다. 매일 약 9,000개 도메인이 X25519 이외의 알고리즘으로 선호가 바뀌고 있으며 대부분 post-quantum으로 직행합니다. 스캔 대상 도메인의 오리진 연결 HRR 비율은 약 52%에서 3.7%로 하락했고, p90 핸드셰이크 지연이 150ms 이상 줄었습니다. post-quantum 가능 오리진의 99.2%가 이제 단일 왕복으로 핸드셰이크를 마치며, post-quantum 오리진 트래픽은 하루 약 250억에서 450억 연결로 증가했습니다. 능동 프로빙 덕분에 트래픽만 관찰해서는 드러나지 않던 수천 개의 '숨은' post-quantum 지원 오리진도 발견됐습니다.

확인 방법과 남은 과제

자신의 서버가 post-quantum을 지원하는지는 Cloudflare Radar에서 확인할 수 있으며, 다중 패킷 ClientHello를 떨구는 미들박스나 비정상 종료 같은 구현 버그의 원인까지 진단해 줍니다. 오리진이 아직 미지원이라면 Cloudflare Tunnel을 쓰거나(cloudflared-Cloudflare 구간은 이미 post-quantum), TLS 엔드포인트를 업그레이드하면 됩니다. 단 수동으로 허용 곡선을 설정해 둔 경우 새 기본값을 덮어쓸 수 있으니 로드밸런서·WAF 등 TLS를 종료하거나 검사하는 모든 장비를 점검해야 합니다. 로드맵에는 서브도메인·오리진 단위 세분화, 대시보드/API에서 즉시 재스캔하는 on-demand 스캔, 그리고 ML-DSA 인증서 기반 post-quantum 오리진 인증과 다운그레이드 공격 방어가 있습니다.

Hacker News 반응

• @chrismorgan — 왜 이걸 진작 안 했는지 궁금합니다. 크리티컬 패스에 있는 뻔한 로우행잉 프루트 같은데, 내가 모르는 뭔가가 있을 거라고 질문했습니다.
• @edelbitter — 추측이지만, 모든 프록시에 배포해야 할 상태가 하나 더 늘어나는 것이라고 답했습니다. 각 프록시가 받는 설정·상태가 많아질수록 이상 동작의 원인 파악이 어려워지며, 실제로 심각한 장애 중 하나가 배포 채널의 데이터 한도 초과(rust panic)에서 비롯됐다고 지적했습니다.
• @sandeepkd — 요약하자면 TLS 핸드셰이크의 알고리즘 발견 단계가 첫 추측 실패 시 왕복을 추가하는데, Cloudflare가 오리진을 매일 스캔해 결과를 저장해 그 왕복을 아낀다는 것이며, 기사에서 빠진 것은 이제 매 연결마다 추가되는 조회 지연의 절대값이라고 지적했습니다.
• @sophacles — 어떤 지연이 추가되냐고 반문하며, 캐시 미스 시 어차피 '이 도메인의 오리진이 어디인지'를 조회해야 하므로 이는 그 레코드에 몇 바이트 더하는 수준이라고 반박했습니다.
• @sandeepkd — 수집한 알고리즘 데이터를 데이터스토어에서 확인해야 한다는 것이, 추측 대신 정답을 쓰겠다는 이 기능의 핵심이라고 재차 답했습니다.

원문: Cloudflare Blog / 번역·요약: Trawling