2026년 6월 17일 Cloudflare가 Authenticated Origin Pulls(AOP)와 Custom Origin Trust Store(COTS)에서 ML-DSA 인증서를 수용한다고 발표했습니다. X25519MLKEM768 키 교환과 결합해 엣지↔원본 종단 간 사후 양자(post-quantum) 인증이 완성됩니다.

“양자 컴퓨터가 언제 위협이 될까”는 여전히 논쟁이지만, TLS 인프라를 다루는 사람들은 지금 준비를 시작해야 합니다. 이 글에서는 무엇이 바뀌는지, 자체 서버 운영자가 오늘 할 수 있는 준비는 무엇인지 정리합니다.

ML-KEM·ML-DSA — 사후 양자 표준 두 가지

NIST가 2024년 표준화 완료한 사후 양자 알고리즘.

  • ML-KEM (구 Kyber): 키 교환(KEM). TLS의 ECDHE·RSA 키 교환을 대체.
  • ML-DSA (구 Dilithium): 디지털 서명. TLS 인증서 서명·RSA·ECDSA 서명을 대체.

두 알고리즘 모두 격자(lattice) 문제 기반. 양자 컴퓨터의 Shor 알고리즘에 취약한 RSA·ECC와 달리 양자 컴퓨터에도 안전하다고 여겨집니다.

X25519MLKEM768 하이브리드 — 왜 하이브리드인가

X25519(고전) + ML-KEM-768(사후 양자)을 동시에 협상하는 방식. 왜 사후 양자만 안 쓰나?

  • 사후 양자 알고리즘이 상대적으로 새로워 아직 완전히 검증되지 않았음.
  • 격자 기반 알고리즘에 미래에 새 취약점이 발견될 가능성 배제 못 함.
  • 하이브리드로 두 알고리즘이 모두 뚫려야 세션이 뚫림 → 안전 여유.

크롬·파이어폭스가 이미 X25519MLKEM768을 표준으로 협상 중. Cloudflare 엣지도 이 협상을 오래 전에 시작했습니다.

이번 발표는 엣지→원본 방향에도 이걸 확장한 것. 이전에는 엣지↔사용자만 사후 양자였는데, 이제 엣지↔원본까지 종단 간.

AOP·COTS가 뭐였고 왜 관련되나

  • AOP (Authenticated Origin Pulls): Cloudflare 엣지가 원본 서버에 요청을 보낼 때 클라이언트 인증서로 자신을 인증. “이 요청은 진짜 Cloudflare 엣지에서 왔다”를 원본이 검증.
  • COTS (Custom Origin Trust Store): 원본 서버가 인정하는 CA 목록을 커스텀. 특정 CA만 신뢰.

두 기능 모두 X.509 인증서를 사용. 지금까지는 RSA·ECDSA 서명 인증서만 지원했는데, 이제 ML-DSA 서명 인증서도 수용. 즉 엣지↔원본의 상호 인증을 사후 양자로 갈아탈 수 있습니다.

자체 서버 운영자에게 이게 왜 중요한가

TCP-80.NET의 일본 VPS·전용서버에서 자체 웹서버를 운영한다면, 지금 당장은 다음을 확인·준비하는 게 실용적입니다.

1) OpenSSL 3.5+ 로 업데이트

OpenSSL 3.5 (2025년 4월)부터 ML-KEM·ML-DSA가 실험적 지원. 정식은 3.6부터.

# Ubuntu 24.04 이후 기본 openssl 확인
openssl version

# 3.5 미만이면 소스 빌드 또는 apt upgrade 대기

Ubuntu 22.04는 아직 3.0. 24.04도 3.0 기반. 사후 양자 정식 지원은 25.04 예정.

2) liboqs / OQS-OpenSSL로 실험

정식 지원 전에 실험하려면 Open Quantum Safe(OQS) 프로젝트.

git clone https://github.com/open-quantum-safe/liboqs
git clone https://github.com/open-quantum-safe/oqs-provider

# 빌드 후 OpenSSL provider로 등록
export OPENSSL_MODULES=/usr/local/lib/ossl-modules

이걸로 하이브리드 X25519MLKEM768 인증서·키 교환을 로컬에서 실험 가능.

3) 인증서 알고리즘 실측

현재 사이트의 TLS 협상이 어느 알고리즘을 쓰는지 확인.

openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>&1 \
  | grep -i "server temp key"

# 크롬 브라우저: chrome://net-internals/#events → 특정 요청 SSL 핸드셰이크에서 group 확인

크롬은 자동으로 X25519MLKEM768을 협상 시도. 서버가 지원 안 하면 X25519로 폴백.

4) TLS 1.3 강제

사후 양자는 TLS 1.3 위에서만 동작. 아직 1.2를 허용 중이면 사후 양자 대응 이전에 1.3 강제부터.

# Nginx
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;

TLS 1.2 클라이언트 지원이 여전히 필요하면 TLSv1.2 TLSv1.3으로. 완전 1.3만은 옛 클라이언트 배제 위험.

5) 인증서 발급자(CA) 로드맵 확인

Let’s Encrypt·DigiCert·Sectigo 등 주요 CA가 언제 ML-DSA 서명 인증서를 발급하는지. 대부분 2026~2027년 로드맵. 발급 가능해지면 순차 전환.

Harvest Now, Decrypt Later — 왜 지금 준비하나

양자 컴퓨터가 아직 실용적 위협이 아닌데 왜 서두를까?

공격자가 오늘 암호화된 트래픽을 그대로 저장했다가 미래 양자 컴퓨터로 복호화하는 시나리오 때문. 국가 정보기관은 이미 이걸 하고 있다는 관측이 있습니다.

  • 지금 저장된 트래픽 = 10~20년 뒤 양자 컴퓨터로 뚫릴 가능성.
  • 그때까지 유효한 비밀(개인정보·금융·의료·기업 기밀)이 있다면 지금 사후 양자로 옮겨야 함.

즉 “언제 양자 컴퓨터가 나오나”가 아니라 “우리 데이터가 얼마나 오래 비밀이어야 하나” 가 기준.

성능 영향

ML-KEM-768:

  • 공개키 1184 bytes (X25519는 32 bytes)
  • 캡슐 1088 bytes
  • 핸드셰이크 크기 증가

ML-DSA-65:

  • 공개키 1952 bytes
  • 서명 3309 bytes
  • 인증서 크기 크게 증가

핸드셰이크 지연이 미미하게 증가(수 ms). 처리량은 큰 영향 없음. 다만 인증서·핸드셰이크 크기가 커져 저대역 모바일에서 초기 로딩 지연이 있을 수 있음.

Cloudflare를 안 써도 준비할 수 있는 것들

  • OpenSSL 3.5+ 로 로컬 실험 환경 구축.
  • 인증서 관리 자동화(certbot·acme.sh)를 최신 버전으로 유지 → 향후 ML-DSA 인증서 지원 시 즉시 반영.
  • TLS 1.3 강제.
  • 백엔드 마이크로서비스 간 mTLS도 사후 양자로 갈 수 있게 라이브러리 업데이트.

언제 프로덕션 도입하나

2026~2027년: 실험·PoC. 2028년: 웹 브라우저·CDN·주요 사이트에서 정식 도입 확산. 2030년: 사실상 표준.

너무 빨리 도입하면 옛 클라이언트·인프라 호환성 문제. 너무 늦으면 harvest-now attack에 노출. 대략 2027년쯤에 프로덕션 전환을 목표로 계획하는 게 실무적.

마무리

사후 양자 암호화는 이제 SF가 아니라 표준화·프로덕션 단계입니다. TLS 인프라 운영자는 5년 안에 한 번은 크게 갈아엎어야 합니다. Cloudflare는 그 준비를 앞서서 하고 있고, 우리 자체 서버도 지금 실험·모니터링을 시작해야 합니다.

TCP-80.NET의 VPS·전용서버 고객 중 TLS 인프라 감사·사후 양자 대비 검토가 필요하시면 @tcp80net 텔레그램으로 문의 주시면 됩니다.

출처 (Source)

이 글은 아래 Cloudflare 공식 changelog를 참고해 tcp-80.net 청중 관점에서 재구성·번역·확장했습니다. 자체 서버 사후 양자 준비 실무(OpenSSL 3.5+·liboqs·OQS-OpenSSL·TLS 1.3 강제·harvest-now-decrypt-later·로드맵 예측)는 원문에 없는 자체 추가 내용입니다.

사후 양자 알고리즘·표준·툴체인은 빠르게 발전 중입니다. 최신 정보는 원문·NIST 공식 문서·OQS 프로젝트에서 확인하시기 바랍니다.