양자내성 TLS 지원 확인하는 법

문제

보안 점검표, 고객사 설문, 정부 로드맵의 한 줄 — 어디선가 “우리 사이트는 양자내성암호를 지원하나요?”라는 질문이 왔는데 어떻게 답해야 할지 모르는 상황입니다.

공개 웹사이트에 대해서는 이 질문에 정확한 답이 있습니다. 서버가 TLS 1.3에서 하이브리드 양자내성 키 교환을 협상하는가. 지금 기준으로는 기존 X25519와 ML-KEM(NIST FIPS 203)을 결합한 그룹 X25519MLKEM768입니다. IETF가 2026년 8월 RFC 10024에서 권장 하이브리드 그룹으로 표준화했고, 최신 크롬·파이어폭스·사파리가 모두 기본으로 제안합니다. 서버가 이를 받아들이면, 최신 브라우저와의 모든 연결의 세션 키가 미래의 양자컴퓨터로부터도 보호됩니다.

양자내성이 바꾸는 것과 바꾸지 않는 것

• 키 교환을 바꿉니다. 위협은 “지금 수집, 나중에 해독”입니다. 기록된 TLS 세션이 디스크에 쌓여 있다가, 양자컴퓨터가 X25519나 ECDHE를 깰 수 있게 되는 날 해독됩니다. 하이브리드 키 교환은 이 문을 닫습니다. 세션을 깨려면 ML-KEM까지 깨야 하기 때문입니다.
• 인증서는 아직 바꾸지 않습니다. 공인 인증기관은 ML-DSA 인증서를 발급하지 않습니다. RSA·ECDSA 인증서를 그대로 쓰는 것은 정상이고, 지금 고칠 수 있는 공백도 아닙니다.
• TLS 1.3이 필요합니다. 하이브리드 그룹은 TLS 1.3에만 있습니다. TLS 1.2에 머문 서버는 먼저 업그레이드해야 합니다.
• “하이브리드”는 타협이 아니라 핵심입니다. ML-KEM에 결함이 드러나더라도 X25519가 세션을 지킵니다. 주요 배포가 ML-KEM 단독이 아니라 하이브리드를 쓰는 이유입니다.

확인하는 세 가지 방법

1. DechoNet 양자내성 TLS 점검. OpenSSL 3.5를 쓰는 서버에서 TLS 1.3 핸드셰이크에 X25519MLKEM768 하나만 제안합니다. 완료되면 “지원”, handshake_failure 경고면 “미지원”, 시간 초과면 “미지원”이 아니라 “판정 보류”로 표시합니다. 그리고 누가 응답했는지 — 기관 서버인지 앞단 CDN 엣지인지 — 와 인증서 체인 각각의 서명 알고리즘도 함께 보여 줍니다.

2. 내 PC에서 OpenSSL 3.5 이상으로:

   openssl s_client -connect example.com:443 -servername example.com -groups X25519MLKEM768 </dev/null

   핸드셰이크가 완료되면 지원입니다. sslv3 alert handshake failure가 보이면 미지원입니다. 오래된 OpenSSL은 그룹 이름 자체를 거부하는데, 그건 서버가 아니라 내 클라이언트 문제입니다.

3. 브라우저. 최신 크롬에서 개발자 도구 → Security 탭의 연결 정보에서 키 교환을 봅니다. 빠르지만, 내 브라우저가 닿은 엣지 기준이라 CDN일 수 있습니다.

결과 읽는 법

보이는 결과	의미	할 일
준비됨 — 원 서버가 X25519MLKEM768을 수락	이 엔드포인트의 기록된 통신이 끝까지 보호됨	감시를 걸어, 설정 변경으로 꺼지면 알 수 있게
부분(CDN) — CDN 엣지가 수락	방문자→엣지는 보호, 엣지→원 서버는 밖에서 안 보임	원 서버의 TLS 스택 확인(아래)
미준비 — 하이브리드 단독 핸드셰이크 거절	지금 모든 세션이 기존 키 교환만 사용	CDN과 원 서버에서 켜기
판정 보류	시간 초과·연결 재설정으로 결론 없음	다시 실행. “미지원”으로 보지 말 것

켜는 방법

• CDN 뒤에 있다면: 대부분의 CDN이 엣지에서 하이브리드 키 교환을 기본으로 켜 두거나 설정으로 제공합니다. 방문자 쪽은 이걸로 해결됩니다. 그다음 원 서버를 보세요. CDN도 원 서버가 지원해야 원 서버 방향으로 ML-KEM을 쓸 수 있습니다.
• nginx·Apache + OpenSSL: 서버에 링크된 OpenSSL이 3.5 이상이어야 합니다. 서버에서 nginx -V나 openssl version으로 확인하세요. 그다음 하이브리드 그룹을 맨 앞에 둡니다.
  • nginx: ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
  • Apache httpd: SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1
• Go 서비스·Caddy: Go 1.24 이상은 X25519MLKEM768을 기본으로 제안하므로, 최신 툴체인으로 다시 빌드하는 것으로 대개 충분합니다.
• 관리형 로드밸런서: ML-KEM이나 “post-quantum”이 들어간 TLS 정책을 찾아 바꾸세요.

하이브리드 그룹 뒤에 X25519를 남겨 두세요. 아직 ML-KEM을 모르는 클라이언트는 X25519로 내려가는데, 그게 정확히 원하는 동작입니다.

DechoNet으로 진단

• 양자내성 TLS 점검은 한 번에 전체 질문에 답합니다: 하이브리드 키 교환 여부, 원 서버와 CDN 구분, TLS 버전, 인증서 체인 서명 알고리즘, 0~100점. 결과 화면에서 매일 감시를 걸면 지원이 생긴 날 — 또는 이전 작업 뒤 사라진 날 — 이 기록됩니다.
• SSL 확인은 같은 엔드포인트의 기존 암호 쪽을 봅니다: 인증서 유효성, 체인, 만료, TLS 버전. 여기서 빨간불부터 고치세요. 체인이 깨진 사이트에 양자내성 키 교환은 도움이 되지 않습니다.
• HTTP 확인은 변경 뒤에도 HTTPS 엔드포인트가 실제로 사이트를 제공하는지, HSTS와 리다이렉트가 그대로인지 확인합니다.

해결 체크리스트

• 엔드포인트가 TLS 1.3을 협상하는지 확인 — 그 아래에는 하이브리드 키 교환이 없습니다.
• X25519MLKEM768 하나만 제안해서 테스트(DechoNet, openssl s_client -groups, curl --curves).
• CDN이 응답한다면 거기서 하이브리드 키 교환을 켜고, 원 서버는 따로 확인.
• 원 서버를 OpenSSL 3.5 이상(또는 Go 1.24 이상)으로 올리고 그룹 목록 맨 앞에 X25519MLKEM768, 그 뒤에 X25519.
• 배포 후 다시 테스트하고, 나중의 설정 변경이 조용히 끄지 못하도록 감시를 걸기.
• 인증서는 그대로 — 공개 양자내성 인증서는 아직 없습니다.

이럴 땐 다음 단계로

• 하이브리드 그룹을 켠 뒤 일부 클라이언트가 접속하지 못하면 중간 장비를 의심하세요. 하이브리드 키 공유 때문에 ClientHello가 약 1KB 커지는데, ClientHello가 한 패킷이라고 가정하는 오래된 방화벽이나 TLS 검사 프록시가 이를 떨굴 수 있습니다. ML-KEM을 되돌릴 일이 아니라 중간 장비를 고칠 일입니다.
• 원 서버가 직접 설정할 수 없는 관리형 서비스(호스팅 패널, 어플라이언스) 뒤에 있다면, 업그레이드 경로는 공급사에 있습니다. OpenSSL 3.5나 양자내성 TLS 정책 일정을 문의하세요.
• 내부 — VPN, DB, 서비스 간 TLS, 코드 서명 — 까지 필요하다면 그건 외부 점검이 아니라 암호 자산 인벤토리입니다. 외부 테스트로는 보이지 않습니다. 이 모든 일정의 배경은 양자내성암호 전환 일정을 보세요.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

진단