클라우드플레어가 오리진 서버와의 TLS 1.3 연결에서 발생하던 불필요한 왕복 지연을 걷어내는 'Automatic Key Exchange(AKE)'를 공개했다. 기존 Automatic SSL/TLS 기능의 확장으로, 오리진이 어떤 키 교환 알고리즘을 지원하고 선호하는지 사전에 탐지한 뒤 첫 연결부터 최적의 알고리즘을 제시하는 방식이다. 회사는 이 기능을 순차 적용하면서 HelloRetryRequest(HRR) 발생률이 약 52%에서 3.7%로 떨어졌고, p90 기준 핸드셰이크 지연이 150ms 이상 줄었다고 밝혔다.
TLS 1.3의 '한 번의 추측' 문제
이 문제의 뿌리는 TLS 1.3 프로토콜 자체에 있다. TLS 1.3은 연결을 여는 첫 패킷(ClientHello)에서 클라이언트가 사용할 키 교환 알고리즘을 미리 확정해 키셰어를 함께 보내야 한다. 상대가 아직 자신의 지원 범위를 알려주기 전에 추측을 강요받는 셈이다. 추측이 맞으면 단 한 번의 왕복으로 핸드셰이크가 끝나지만, 오리진이 다른 알고리즘을 선호하면 HRR을 돌려보내 클라이언트가 새 키셰어로 다시 시도하게 만든다. 이때 왕복이 한 번 더 추가된다. 이 예측형 키 교환은 TLS 1.3이 1.2보다 빠른 핵심 이유이기도 하지만, 예측이 빗나가면 그 이점을 그대로 반납한다.
여기서 짚어둘 구조가 있다. 클라우드플레어는 리버스 프록시이므로 겉보기에 하나인 보안 연결이 실제로는 둘이다. 방문자와 클라우드플레어 사이, 그리고 클라우드플레어와 오리진 사이다. AKE가 손대는 것은 후자다. 오리진 쪽 연결에서는 클라우드플레어가 TLS 클라이언트 역할을 맡아 ClientHello를 먼저 보내며, 바로 이 지점에서 알고리즘을 추측해야 했다.
안전했지만 느렸던 기본값
수년간 클라우드플레어의 추측값은 모든 오리진에 대해 X25519로 고정돼 있었다. 오리진의 95% 이상이 X25519를 지원하고, 지원하지 않는 곳도 HRR로 재협상하면 연결이 끊기지는 않았기에 안전한 선택이었다. 문제는 X25519가 양자 컴퓨터에 취약하다는 점이다. 클라우드플레어는 2023년 9월부터 오리진에 양자내성 키 교환(현재는 표준화된 X25519MLKEM768)을 광고해 왔지만, '지원을 광고하는 것'과 '첫 패킷에서 그 키셰어를 앞세우는 것'은 다르다. X25519MLKEM768 키셰어는 1,216바이트로 X25519의 32바이트보다 훨씬 커 ClientHello가 단일 패킷을 넘어선다. 일부 구형 미들박스나 오리진은 여러 패킷으로 쪼개진 ClientHello를 처리하지 못해, 이전 조사에서 스캔한 오리진의 약 0.34%가 양자내성 키셰어를 먼저 받으면 핸드셰이크에 실패했다.
그래서 회사는 HRR을 일종의 안전밸브로 삼았다. 양자내성 지원만 광고하고 실제로는 고전 X25519 키셰어를 보낸 뒤, 능력이 되는 오리진이 재협상으로 양자내성 교환을 요청하도록 한 것이다. 결과적으로 양자내성 연결은 거의 예외 없이 두 번째 왕복을 강제로 치러야 했다. 오리진의 양자내성 지원율은 2023년 0.5%에서 현재 12.8%로 늘었지만, 이 지원을 살리려면 대시보드에서 수동 설정을 켜야 했고 잘못 건드리기도 쉬웠다.
추측 대신 측정으로
AKE의 핵심은 추측을 측정으로 바꾼 것이다. Automatic SSL/TLS를 떠받치던 기존 스캐닝 파이프라인을 재활용해 오리진을 대역 외(out-of-band)로 탐지하고, 오리진별로 첫 키셰어를 맞춤 설정한다. 능력이 되는 오리진에는 첫 시도부터 X25519MLKEM768을 앞세워 추가 왕복 없이 양자내성 키 합의를 성사시킨다. 능동 탐지가 중요한 이유는, 양자내성을 지원하는 오리진이라도 X25519 키셰어를 HRR 없이 그냥 수용하는 경우가 많아 실제 트래픽만 수동적으로 관찰해서는 오리진의 전체 능력을 알 수 없기 때문이다. 클라우드플레어는 능동 탐지로 트래픽에는 드러나지 않던 수천 개 오리진의 양자내성 지원을 발굴했다고 설명한다.
100만 개가 넘는 도메인에 이미 키 교환 선호도가 부여됐는데, 이 중 약 64%는 X25519를 그대로 유지해 아무 변화가 없었고, 약 33%는 X25519MLKEM768로 전환됐다. 나머지 3%는 P-384, P-256, P-521 같은 다른 고전 곡선을 선택했다. 하루 약 9,000개 도메인이 X25519 외의 알고리즘으로 선호도가 바뀌며, 대부분은 곧장 양자내성 교환으로 이동한다. 그 결과 현재 스캔된 오리진에서 양자내성 TLS 1.3 연결의 99.2%가 단일 왕복으로 완료되고, 양자내성 오리진 트래픽은 하루 약 250억 건에서 450억 건 규모로 늘었다.
실무자가 유의할 점
이 배경에는 '수확 후 복호화(harvest-now, decrypt-later)' 위협이 있다. 공격자가 지금은 못 읽는 암호화 트래픽을 저장해 두었다가 훗날 해독하려는 시나리오로, 클라우드플레어는 고전 암호가 깨질 수 있다고 일부 전문가가 추정하는 이른바 'Q-Day'를 2029년으로 잡고 인터넷의 양자 안전화를 서두르고 있다. 수백만 웹 운영자가 저마다 암호학 전문가가 될 수는 없으니 자동화가 답이라는 논리다. AKE는 기존·신규 도메인 모두에 기본 활성화되며, 별도 설정 없이 대부분 자동으로 최강 알고리즘이 협상된다. 필요하면 대시보드 SSL/TLS > Overview > Configure에서 직접 관리할 수 있다.
다만 새로 추가된 'Compliance requirements' 설정은 신중히 다뤄야 한다. 이 옵션은 클라우드플레어가 협상할 수 있는 알고리즘 범위를 좁힐 뿐, 오리진에 없던 암호 능력을 새로 부여하지는 않는다. 특히 X25519MLKEM768을 지원하지 않는 오리진에 양자내성 하이브리드를 강제하면 상호 지원되는 알고리즘이 사라져 해당 오리진의 모든 TLS 1.3 연결이 실패한다. 엄격한 정책 의무나 FIPS 요건이 없다면 두 옵션을 모두 비워두고 AKE가 안전하게 협상하도록 두는 편이 낫다. 또한 AKE는 오리진이 TLS 1.3을 구사하는 도메인에서만 작동한다는 전제도 기억해 둘 만하다.