원본 서버와의 TLS 핸드셰이크, 절반이 헛돌고 있었다
Cloudflare 블로그에 흥미로운 글이 올라왔어요. Cloudflare가 고객의 원본 서버(origin, 실제 웹 앱이 돌아가는 서버)와 맺는 TLS 연결 중 무려 52%에서 HelloRetryRequest라는 게 발생하고 있었는데, 이걸 AKE(Automatic Key Exchange, 자동 키 교환)라는 기능으로 3.7%까지 줄였다는 내용이에요. 숫자만 보면 “그래서 뭐?” 싶을 수 있는데, 이게 뭘 의미하는지 알고 나면 꽤 재미있거든요.
배경부터 볼게요. Cloudflare 같은 CDN이나 리버스 프록시를 쓰면 방문자의 브라우저는 Cloudflare에 접속하고, Cloudflare가 다시 여러분의 원본 서버에 접속해서 콘텐츠를 가져와요. 이 두 번째 구간에서 Cloudflare는 ‘서버’가 아니라 ‘TLS 클라이언트’ 역할을 해요. 즉 브라우저가 하는 일을 Cloudflare가 대신 하는 거죠.
이게 뭐냐면: TLS 1.3의 HelloRetryRequest
TLS 1.3은 핸드셰이크를 한 번의 왕복(1-RTT)으로 끝내는 게 큰 자랑이에요. 어떻게 그게 가능하냐면, 클라이언트가 첫 메시지인 ClientHello를 보낼 때 “나는 이런 암호 그룹들을 지원하고, 그중 이 그룹으로 미리 키 재료(key_share)를 만들어서 같이 보낼게”라고 선수를 치거든요. 서버가 그 그룹을 지원하면 바로 응답해서 키 교환이 한 번에 끝나요.
문제는 서버가 클라이언트가 미리 만들어 보낸 그룹을 지원하지 않을 때예요. 그러면 서버는 “미안, 그 그룹 말고 다른 걸로 다시 보내줘”라는 HelloRetryRequest(줄여서 HRR)를 보내고, 클라이언트는 ClientHello를 다시 보내야 해요. 왕복이 한 번 더 늘어나는 거죠. 서울에서 미국 서버까지 왕복 지연이 150ms라면, 연결 하나마다 150ms를 그냥 버리는 셈이에요.
왜 절반이나 HRR이 났을까
여기서 포스트 양자 암호가 등장해요. 양자 컴퓨터가 실용화되면 지금 쓰는 X25519나 P-256 같은 키 교환 방식은 깨질 수 있어서, 업계는 ML-KEM이라는 양자 내성 알고리즘을 기존 방식과 섞은 하이브리드 키 교환(X25519MLKEM768)으로 넘어가는 중이에요. Chrome, Firefox 같은 브라우저는 이미 기본으로 켜져 있고, Cloudflare도 원본 서버에 접속할 때 이 하이브리드 그룹을 우선으로 제안하고 있었어요.
그런데 원본 서버 쪽은 사정이 달라요. 오래된 OpenSSL, 업데이트 안 된 nginx, 각종 클라우드 로드밸런서 중 상당수가 아직 ML-KEM 하이브리드를 지원하지 않거든요. Cloudflare가 매번 “포스트 양자 그룹으로 키 재료 보낼게” 했더니, 절반이 넘는 원본 서버가 “그거 몰라, X25519로 다시 보내”라고 HRR을 돌려준 거예요. 보안을 강화하려다가 성능이 깎이는 상황이었던 거죠.
물론 “그럼 X25519와 ML-KEM 키 재료를 둘 다 보내면 되지 않나?” 생각할 수 있는데요. ML-KEM 키 재료는 1KB가 넘어서 ClientHello가 뚱뚱해지고, 매 연결마다 두 종류의 키를 생성하는 CPU 비용도 들어요. Cloudflare 규모에서는 이것도 무시 못 할 낭비예요.
AKE가 하는 일
AKE의 아이디어는 단순해요. 원본 서버마다 “얘는 어떤 키 교환 그룹을 받아주더라”를 기억해 두는 거예요. 처음 접속할 때 HRR을 받으면 그 서버가 지원하는 그룹을 학습해 두고, 다음 연결부터는 처음부터 그 서버가 받아줄 그룹으로 키 재료를 만들어 보내요. 포스트 양자를 지원하는 서버에는 계속 ML-KEM 하이브리드를, 아직 안 되는 서버에는 X25519를 첫 시도부터 보내는 거죠. 그 결과가 52%에서 3.7%로의 감소예요.
0%가 아닌 이유도 생각해볼 만해요. 원본 서버 관리자가 설정을 바꾸거나, 로드밸런서 뒤에 서로 다른 버전의 서버가 섞여 있거나, 기억해 둔 정보가 만료됐을 때는 여전히 HRR이 발생할 수밖에 없거든요. 그래도 이건 자연스러운 잔여분이에요. 중요한 건 서버가 포스트 양자를 지원하기 시작하면 다시 그쪽으로 자동으로 올라탄다는 점이에요. 보안을 낮추는 방향으로 고정하는 게 아니라, 서버 상태에 맞춰 계속 최선을 고르는 거죠.
업계 맥락
사실 HRR 문제는 브라우저 쪽에서 먼저 겪었던 일이에요. Chrome이 Kyber(ML-KEM의 이전 이름)를 처음 켰을 때 일부 서버와 미들박스가 커진 ClientHello를 제대로 처리 못 해서 연결이 깨지는 사고가 있었죠. 브라우저는 “그래도 보안이 우선”이라며 밀어붙였고, 서버 쪽 생태계가 따라오면서 자리를 잡았어요. Cloudflare의 이번 글은 그 같은 전환을 원본 서버 방향에서 겪고 있다는 걸 보여줘요. OpenSSL 3.5, Go 1.24, BoringSSL 등 주요 TLS 라이브러리는 이미 ML-KEM 하이브리드를 지원하니, 남은 건 실제 서버들이 업데이트되는 시간 문제예요.
한국 개발자에게 주는 시사점
Cloudflare를 쓰고 계시다면 아무것도 안 해도 이득을 보는 기능이에요. 하지만 더 근본적으로는 여러분의 원본 서버가 포스트 양자 키 교환을 지원하는지 한번 확인해보세요. OpenSSL 3.5 이상으로 올리고 nginx나 Caddy를 최신으로 유지하면 대부분 자동으로 켜져요. 그러면 HRR도 없고 양자 내성도 얻으니 일석이조죠. 확인은 간단해요. 최신 Chrome으로 접속해서 개발자 도구의 Security 탭을 보면 키 교환 방식이 X25519MLKEM768로 표시되는지 알 수 있어요.
또 하나, 자체 프록시나 서비스 메시, 내부 게이트웨이를 만드는 분들에게는 “상대방과의 협상 결과를 캐시해 두고 다음번엔 처음부터 맞춰서 간다”는 이 패턴 자체가 배울 만해요. TLS뿐 아니라 HTTP 버전 협상, 압축 방식 협상 등 어디든 적용할 수 있는 최적화 아이디어거든요.
마무리
한 줄로 정리하면, “포스트 양자 전환기의 성장통인 HRR을, 서버별 지원 그룹을 기억하는 것만으로 거의 없앴다”는 얘기예요. 여러분 회사의 서버는 포스트 양자 키 교환 준비가 되어 있나요? 아직이라면 어떤 게 걸림돌인지 함께 얘기해봐요.
🔗 출처: Hacker News