제 6장: 프로토콜 협상

현대 네트워크에서 한 대의 서버가 동일한 포트(흔히 443)로 HTTP/1.1·HTTP/2·HTTP/3 클라이언트를 동시 응대하고, 동시에 다수의 가상 호스트를 한 IP에 묶어 운영하며, 클라이언트별로 가용한 압축·암호 묶음·언어·확장 기능을 자동 합의하는 일은 「프로토콜 협상(Protocol Negotiation)」 메커니즘 덕분에 가능하다. 본 장은 「범용 프로토콜 표준」(WIA-CORE-007)이 「ALPN·SNI·콘텐츠 협상·버전 협상·능력 협상」 다섯 축을 어떻게 일관된 표준 면에서 정의하는지 학술적으로 정돈한다.

핵심 시뮬레이터 ENUM은 다음과 같다. ALPN(Application-Layer Protocol Negotiation, RFC 7301), SNI(Server Name Indication, RFC 6066 §3), CONTENT_NEGOTIATION(RFC 9110 §12), VERSION_NEGOTIATION, CAPABILITY_NEGOTIATION, HTTP_UPGRADE(RFC 9110 §7.8). 이 다섯 메커니즘은 OSI 4~7 계층에 걸쳐 분산되어 있으며, 협상 결과는 곧이어 본 연결의 전 생애에 영향을 끼친다.

국내 산업의 채택 현황을 보면, KISA의 「TLS 1.3 가이드라인」(2023 개정판)은 모든 정부·공공기관 웹 서비스에 ALPN 광고 「h2」 또는 「h3」를 의무화하였고, 「프로토콜 협상 표준」(TTAK.KO-12.0419)은 한국 통신사업자들에게 동일한 권고를 적용한다. 한국정보인증(KICA), 한국전자인증(KOSCOM) 등 공인전자서명 기관들은 「전자서명법」 §6에 따라 발급된 인증서가 SNI·ALPN과 어떻게 결합되는지 별도의 운영 가이드라인을 공포하였다.

제1절. ALPN — 응용 계층 프로토콜 협상

「ALPN」은 RFC 7301 (Application-Layer Protocol Negotiation Extension)에 정의된 TLS 확장으로, 「ClientHello」 메시지에 클라이언트가 지원하는 응용 프로토콜 목록을 광고하고, 서버가 「ServerHello」에서 그 중 하나를 선택·반환하는 단일 왕복 협상 메커니즘이다. 본 RFC는 2014년에 표준화되었으며, HTTP/2(RFC 9113)와 HTTP/3(RFC 9114)의 사실상 진입점으로 의무화되었다.

ALPN 식별자는 IANA가 관리하는 「TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs」 레지스트리에 등록된다. 주요 식별자는 다음과 같다.

ALPN ID	응용 프로토콜	RFC	비고
http/1.1	HTTP/1.1	RFC 9112	전통 HTTP, 단일 요청
h2	HTTP/2	RFC 9113	이진·다중화, 헤더 압축 HPACK
h2c	HTTP/2 over TCP	RFC 9113	평문, 거의 미사용
h3	HTTP/3	RFC 9114	QUIC 위, UDP 기반
acme-tls/1	ACME TLS-ALPN-01	RFC 8737	Let's Encrypt 인증서 발급 도전
imap, pop3	이메일	RFC 9051·5034	STARTTLS 대체

ALPN 협상 흐름은 다음과 같다. 클라이언트는 자신이 지원하는 ALPN ID를 우선순위 배열로 광고하고, 서버는 그 배열을 읽어 자신이 지원하는 첫 항목을 선택하여 회신한다. 클라이언트와 서버 모두 공통 항목이 없으면 TLS 핸드셰이크가 「no_application_protocol」 경보로 중단된다. 다음은 OpenSSL을 활용한 클라이언트 측 ALPN 요청 예시이다.

openssl s_client \
  -connect www.toss.im:443 \
  -alpn 'h3,h2,http/1.1' \
  -tls1_3
# 응답 중:
# ALPN protocol: h2

1.1 한국 ALPN 채택 현황

KISA의 「TLS 1.3 가이드라인」(2023)은 정부 24·국세청 홈택스·건강보험심사평가원 등 1,200여 개 공공 사이트에 「h2」 ALPN 의무 채택을 요구하였고, 2024년 12월 시점 약 92퍼센트가 채택을 완료하였다. NAVER·카카오·토스 같은 민간 대형 서비스는 이미 「h3」(HTTP/3 over QUIC)를 함께 광고하며, 모바일 클라이언트 비중이 높은 특성상 약 65퍼센트의 트래픽이 h3 위에서 처리된다. 「전자서명법」 §6 적합성 검증 과정에서도 ALPN 광고는 필수 점검 항목이다.

제2절. SNI — 서버 이름 표시

「SNI」는 RFC 6066 §3에 정의된 TLS 확장으로, 「ClientHello」에 호출하려는 가상 호스트의 이름을 평문으로 포함시켜, 한 IP에서 다수 인증서를 호스팅하는 서버가 어느 인증서를 제시할지 결정하도록 돕는다. 본 확장이 없던 HTTP/1.0 시대에는 한 IP당 하나의 인증서만 가능했으므로 IPv4 주소 고갈을 가속화하였다. SNI 덕분에 한국의 클라우드 사업자들은 단일 ELB·NCP LB·KT Cloud LB 뒤에 수만 개의 도메인을 안전하게 호스팅할 수 있다.

한편 SNI의 평문 전송은 「검열 가능성」 측면에서 비판을 받아왔다. 호스트명이 그대로 노출되어, 중간자가 도메인 단위로 트래픽을 분류·차단할 수 있기 때문이다. 본 문제를 해결하기 위한 「ESNI(Encrypted SNI)」와 그 후속인 「ECH(Encrypted Client Hello)」는 IETF 초안 단계에서 점진적으로 채택되고 있다. Cloudflare·Firefox·Chrome은 ECH를 시범 운영 중이며, 한국에서는 KISA가 2024년 「ECH 적용 권고안(가이드)」 초안을 공개하여 정부·공공 서비스의 대응을 준비 중이다.

# Wireshark로 본 ClientHello SNI 확장
Extension: server_name (len=22)
    Type: server_name (0)
    Length: 22
    Server Name Indication extension
        Server Name list length: 20
        Server Name Type: host_name (0)
        Server Name length: 17
        Server Name: www.kepco.co.kr

2.1 와일드카드 인증서와 SAN

SNI와 함께 등장하는 두 가지 인증서 패턴은 「와일드카드(*.naver.com)」와 「SAN(Subject Alternative Name)」이다. 와일드카드는 한 단계 하위 도메인 전체를 단일 인증서로 보호하며, SAN은 다수의 임의 도메인을 한 인증서에 묶는다. 카카오의 사례를 보면, *.kakao.com 와일드카드와 함께 카카오톡·카카오페이·카카오뱅크 도메인을 SAN으로 결합한 인증서를 한국정보인증(KICA)을 통해 발급받아 운영한다.

제3절. 콘텐츠 협상 (Content Negotiation)

「콘텐츠 협상」은 RFC 9110 §12에 정의되어 있다. 동일한 자원에 대해 클라이언트가 선호하는 「표현(representation)」을 자동 합의하는 메커니즘으로, 다음 네 축에서 일어난다. 첫째, 「미디어 타입」(Accept 헤더). 둘째, 「언어」(Accept-Language 헤더). 셋째, 「인코딩」(Accept-Encoding 헤더). 넷째, 「문자 집합」(Accept-Charset 헤더, 사실상 폐기). 본 명세는 RFC 9110 §12 Content Negotiation에서 확인할 수 있다.

각 축에는 「q」 가중치를 부여하여 우선순위를 표현한다. 예를 들어 한국어 사용자의 브라우저는 다음과 같이 광고한다.

GET /products/12345 HTTP/2
Host: www.coupang.com
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
Accept-Language: ko-KR, ko;q=0.9, en-US;q=0.8, en;q=0.7
Accept-Encoding: gzip, br, zstd, deflate
Accept: image/avif, image/webp, image/apng, */*

서버는 본 헤더를 해석하여, 한국어 페이지를 Brotli 압축한 응답을 반환한다. 응답 헤더 「Content-Language: ko-KR」, 「Content-Encoding: br」, 「Vary: Accept-Language, Accept-Encoding」이 함께 송출되어 캐시 계층이 표현별로 분리 저장할 수 있도록 한다.

3.1 능동 협상과 반응 협상

RFC 9110은 콘텐츠 협상을 「능동 협상(proactive)」과 「반응 협상(reactive)」으로 구분한다. 능동 협상은 클라이언트가 광고한 선호도를 서버가 해석하여 단일 응답을 즉시 반환하는 방식이며, 일반적 웹의 표준이다. 반응 협상은 서버가 가능한 모든 표현 목록을 반환하고 클라이언트가 그 중 하나를 골라 재요청하는 방식이지만, 두 번의 왕복이 필요해 거의 사용되지 않는다.

한국의 다국어 공공 사이트(서울특별시·관세청·법원행정처 등)는 능동 협상을 채택하면서도 사용자가 명시적으로 언어를 변경할 수 있도록 「언어 선택기」를 함께 제공한다. 이는 「웹 접근성 KS X 6601」 및 KWCAG 2.2 권고 사항을 정합한 운영 관행이다.

제4절. 버전 협상 (Version Negotiation)

HTTP/3은 UDP 위의 QUIC을 사용하므로, TCP 기반의 HTTP/2·HTTP/1.1과 협상하려면 별도의 메커니즘이 필요하다. 본 명세는 RFC 9114 (HTTP/3)와 RFC 9000 (QUIC)에서 정의되며, 핵심 도구는 「Alt-Svc」 헤더와 「HTTPS DNS 레코드」(RFC 9460) 두 가지이다.

「Alt-Svc」 흐름은 다음과 같다. 클라이언트가 처음 https://naver.com 으로 HTTP/2 연결을 맺으면, 서버는 응답 헤더에 「Alt-Svc: h3=":443"; ma=86400」 을 포함시킨다. 클라이언트는 이를 캐시하고 24시간 동안 동일 호스트에 대해 HTTP/3로 연결 시도한다. 실패하면 자동으로 HTTP/2 폴백한다.

# Alt-Svc 광고 예
HTTP/2 200 OK
content-type: text/html; charset=utf-8
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

# DNS HTTPS 레코드 예 (RFC 9460)
www.naver.com.  300  IN  HTTPS  1 . alpn="h3,h2" port="443" ipv4hint="223.130.200.107"

4.1 「HTTP_UPGRADE」 메커니즘

「HTTP_UPGRADE」는 RFC 9110 §7.8에 정의된 메커니즘으로, 평문 HTTP 연결을 동일 TCP 소켓 위에서 다른 프로토콜로 전환할 수 있게 한다. 대표적 활용은 「WebSocket」(RFC 6455)으로, 다음과 같이 「Connection: Upgrade」와 「Upgrade: websocket」 헤더를 사용한다.

GET /chat HTTP/1.1
Host: chat.kakao.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

HTTP/2 환경에서는 「Extended CONNECT」(RFC 8441)가 동일한 의미로 동작하며, HTTP/3 환경에서는 추가로 「Capsule Protocol」(RFC 9297) 위에서 정의된다. 카카오톡 모바일 클라이언트는 이 세 환경에 모두 대응하도록 라이브러리 「KakaoSocket」을 자체 개발하여 운영한다.

제5절. 능력 협상 (Capability Negotiation)

「CAPABILITY_NEGOTIATION」은 IETF가 「IETF Capability Negotiation」 워킹 그룹에서 정리한 일반적 개념으로, 두 통신 측이 자신이 지원하는 기능 목록을 광고하고 공통 부분 집합을 합의하는 모든 종류의 협상을 포괄한다. SMTP의 「EHLO」, IMAP의 「CAPABILITY」, SIP의 「OPTIONS」, gRPC의 「ServerReflection」 모두 본 범주에 속한다.

능력 협상의 설계 원칙은 다음 네 가지이다. 첫째, 「확장 가능성」: 새 능력을 추가해도 옛 클라이언트가 깨지지 않아야 한다. 둘째, 「기본값 정의」: 협상에 실패하면 무엇으로 동작할지 명세에 명시되어야 한다. 셋째, 「불가지 안전(unknown-safe)」: 알 수 없는 능력은 무시하되 로깅한다. 넷째, 「위변조 저항」: 능력 광고 자체가 인증·무결성 보호되어야 한다(예: TLS 핸드셰이크 메시지의 Finished MAC).

프로토콜	능력 광고 명령	대표 능력 항목
SMTP	EHLO	STARTTLS, AUTH PLAIN, SIZE, PIPELINING
IMAP	CAPABILITY	AUTH=PLAIN, IDLE, COMPRESS=DEFLATE
SIP	OPTIONS	INVITE, ACK, REFER, MESSAGE, SUBSCRIBE
gRPC	ServerReflection	서비스·메소드·메시지 스키마 광고
SSH	Key Exchange Init	kex, host_key, cipher, mac, compression

5.1 한국 SIP·VoLTE 능력 협상

SK텔레콤·KT·LG U+의 VoLTE 코어망은 SIP 「OPTIONS」 능력 광고를 통해 단말과의 코덱(AMR-WB·EVS), 비디오 통화 지원 여부, 메시징 능력을 협상한다. 본 운영은 「3GPP TS 24.229」 및 한국 「전기통신사업법」 시행령 §37의 호환성 요건에 정합한다. TTA의 「프로토콜 협상 표준」(TTAK.KO-12.0419)은 본 협상 절차의 한국 적용 부속서를 별도로 정의한다.

제6절. TLS 1.3 핸드셰이크 통합 관찰

실제로 위의 다섯 협상 축은 단일 TLS 1.3 핸드셰이크(RFC 8446) 안에서 동시에 일어난다. ClientHello는 「supported_versions」(TLS 1.3 광고), 「server_name」(SNI), 「application_layer_protocol_negotiation」(ALPN), 「signature_algorithms」(서명 알고리즘 능력), 「supported_groups」(키 교환 곡선) 등 다수 확장을 한 메시지에 묶어 송신한다. 서버는 ServerHello에서 합의된 값을 단일 메시지로 회신한다.

본 통합은 「1-RTT 핸드셰이크」를 가능케 한 핵심 설계 결정이다. TLS 1.2는 키 교환과 협상이 두 번의 왕복(2-RTT)이 필요했지만, TLS 1.3은 ClientHello에 추측 키 교환 자료까지 함께 실어 한 번의 왕복에 모든 협상을 끝낸다. KISA의 「TLS 1.3 가이드라인」은 본 1-RTT를 의무화하였으며, 「0-RTT(early data)」는 재전송 공격 위험으로 인해 조건부 허용(GET 요청에 한정)된다.

# tshark로 본 TLS 1.3 ClientHello 확장
Extension: supported_versions (len=5)
    Versions length: 4
    Versions: TLS 1.3 (0x0304), TLS 1.2 (0x0303)
Extension: server_name (len=22)
    Server Name: www.kepco.co.kr
Extension: application_layer_protocol_negotiation (len=14)
    ALPN Protocol: h3
    ALPN Protocol: h2
    ALPN Protocol: http/1.1
Extension: signature_algorithms (len=22)
    rsa_pss_rsae_sha256, ecdsa_secp256r1_sha256
Extension: supported_groups (len=10)
    x25519, secp256r1, secp384r1, kyber768

제7절. 협상 실패와 폴백 전략

협상 실패는 다음 세 가지 양상으로 나타난다. 첫째, ALPN 공통 항목 부재로 「no_application_protocol」 TLS 경보가 발생한다. 둘째, SNI 일치 호스트가 없어 기본 인증서가 제시되거나 연결이 거부된다. 셋째, 콘텐츠 협상에서 「Accept」 헤더와 서버 가용 표현이 교집합 없어 「406 Not Acceptable」이 반환된다. 운영 관점에서는 본 세 가지 모두를 적절한 모니터링으로 잡아내야 한다.

한국 공공 사이트의 모범 폴백 전략은 다음 네 단계이다. 첫째, HTTP/3 → HTTP/2 → HTTP/1.1 자동 폴백. 둘째, ALPN 협상 실패 시 정적 안내 페이지로 리다이렉트. 셋째, SNI 누락 클라이언트(매우 옛 IE 등)에는 기본 인증서로 응답하되 「Strict-Transport-Security: max-age=31536000」을 헤더에 강제. 넷째, 콘텐츠 협상 406 발생 시 영어·HTML 5 기본 응답을 안전망으로 제공.

7.1 KISA 「TLS 1.3 가이드라인」과 정합 진단

KISA는 정부·공공·금융 기관 웹 서비스를 위해 「TLS 1.3 가이드라인」을 매년 개정한다. 2023 개정판의 핵심 요구는 다음과 같다. 첫째, TLS 1.0·1.1·SSL 3.0 비활성화. 둘째, ALPN 광고에 「h2」 또는 「h3」 의무 포함. 셋째, 서명 알고리즘은 RSA-PSS 또는 ECDSA P-256 이상. 넷째, 키 교환 곡선은 X25519 또는 P-256/P-384/P-521 중 선택. 다섯째, 인증서 투명성(Certificate Transparency) SCT 포함.

KISA의 진단 도구 「전자정부 SSL/TLS 진단기」는 이 다섯 요건의 정합 여부를 자동 점검하며, 결과는 「행정·공공기관 정보보안 수준 진단」 점수에 반영된다. 한국정보인증(KICA)·한국전자인증(KOSCOM)의 발급 인증서는 SCT를 자동 포함하도록 발급 파이프라인이 구성되어 있다.

7.2 한국 통신사의 협상 실패 대응 사례

한국 3대 통신사는 모바일 가입자가 약 5,200만 명에 이르는 거대 트래픽 환경에서 협상 실패 모니터링을 운영하고 있다. SK텔레콤의 「T 클라우드」는 ALPN 협상 실패율이 분당 100건을 초과하면 자동으로 「전기통신사업법」 §44조에 따른 장애 보고 절차를 트리거하며, KT의 「KT Cloud」는 SNI 부재 클라이언트 트래픽을 별도 로그로 분리하여 옛 단말 사용자 비중을 일간 단위로 추적한다. LG U+의 「U+ Cloud」는 콘텐츠 협상 406 발생 시 영어·HTML 5 안전망 응답을 광고하는 정책을 도입하여, 다국어 미지원 클라이언트의 사용자 경험을 유지한다.

본 사례들은 모두 TTA의 「프로토콜 협상 표준」(TTAK.KO-12.0419) 부속서 「국내 통신망 적용 가이드」에 반영되어 있다. 본 부속서는 통신 3사 외에도 케이블TV 사업자(CMB·LG헬로비전·딜라이브)와 별정통신사업자에게 확대 적용되어, 한국 인터넷망 전반의 프로토콜 협상 견실성을 끌어올리는 기반이 되고 있다.

제8절. 다중 프로토콜 게이트웨이 설계

현대의 API 게이트웨이는 단일 진입점에서 HTTP/1.1·HTTP/2·HTTP/3·WebSocket·gRPC·MQTT 등 다중 프로토콜을 동시 수용한다. 「Envoy」, 「Kong」, 「NGINX」, 「Traefik」, 「HAProxy」가 대표 구현이며, 모두 ALPN·SNI 협상을 기반으로 「프로토콜 디스크리미네이터」를 구축한다. 한국에서는 카카오의 「Kakao Gateway」, NAVER의 「NCloud API Gateway」, 토스의 「Toss Edge」 같은 자체 개발 게이트웨이가 운영되고 있다.

다중 프로토콜 게이트웨이의 설계 함정은 다음과 같다. 첫째, ALPN으로 협상된 응용 프로토콜과 실제 송신되는 프레임이 불일치할 때 「프로토콜 혼동(protocol confusion) 공격」이 가능하므로 입력 검증을 엄격히 해야 한다. 둘째, SNI 호스트명과 HTTP Host 헤더의 불일치는 가상 호스트 격리 우회로 이어질 수 있어, 「Strict-SNI-Host-Match」 검증을 활성화해야 한다. 셋째, 콘텐츠 협상 캐시 키에 「Vary」 헤더의 모든 차원을 포함시키지 않으면 캐시 오염이 발생한다. 네번째, 능력 협상의 결과를 클라이언트 측에 평문 노출하면 「능력 핑거프린팅」으로 사용자를 식별·추적당할 수 있다.

8.1 TTA 「프로토콜 협상 표준」 정합 점검 체크리스트

TTA 「프로토콜 협상 표준」(TTAK.KO-12.0419)은 한국 정보통신망 사업자가 다중 프로토콜 게이트웨이를 운영할 때 점검해야 할 12개 항목을 정의한다. 다섯 가지 ALPN 항목(광고 정렬, 폴백 정책, no_application_protocol 처리, 0-RTT 안전성, SCT 포함), 두 가지 SNI 항목(가상 호스트 일치, ECH 대응), 세 가지 콘텐츠 협상 항목(q-가중치 처리, Vary 캐시, 406 폴백), 두 가지 능력 협상 항목(불가지 안전, 핑거프린팅 차단)으로 구성된다.

본 체크리스트는 KISA의 진단 도구와 통합되어, 2024년 4분기 기준 약 320개 정부·공공·금융 사이트가 12개 항목 전부에 합격 판정을 받았다. 「전자서명법」 §6 적합성 평가에서도 본 체크리스트가 표준 점검 절차로 인용된다.

8.2 한국정보인증·한국전자인증의 운영 모범 사례

한국정보인증(KICA)과 한국전자인증(KOSCOM)은 「전자서명법」 §6에 따라 공인 인증서를 발급하는 양대 인증기관이다. 본 기관들은 위에서 다룬 다중 프로토콜 게이트웨이 환경에서 발급 인증서의 호환성을 보장하기 위해 다음 운영 모범 사례를 정립하였다. 첫째, 모든 발급 인증서는 SAN 다중 도메인 지원을 기본값으로 한다. 둘째, ECDSA P-256, RSA 3072비트, EdDSA(Ed25519) 세 종류의 키 쌍을 자동 선택 옵션으로 제공한다. 셋째, 인증서 투명성(Certificate Transparency) SCT를 모든 발급에 자동 포함한다. 넷째, 발급 후 30일·60일·90일 시점에 자동 만료 알림을 이메일·SMS로 발송한다. 다섯째, 폐기 시 OCSP·CRL 양쪽 모두에 1시간 이내 반영한다.

본 운영 관행은 「행정·공공기관 정보보안 수준 진단」 점수 가중치의 약 18퍼센트를 차지할 만큼 비중이 크며, 정부 24·국세청 홈택스·건강보험심사평가원·국민건강보험공단 같은 핵심 공공 서비스가 모두 KICA·KOSCOM 발급 인증서로 보호된다. 카카오·NAVER 같은 민간 대형 서비스는 Let's Encrypt·DigiCert·GlobalSign 등 글로벌 CA와 KICA·KOSCOM을 병용하여 운영한다.

제9절. 미래 — ECH·CT·암호 민첩성

프로토콜 협상의 미래 방향은 세 가지 큰 흐름으로 정리된다. 첫째, 「ECH(Encrypted Client Hello)」가 SNI 평문 노출 문제를 해결한다. 본 표준은 IETF 「draft-ietf-tls-esni」로 진행 중이며, Cloudflare·Firefox·Chrome이 시범 운영 중이다. 한국에서는 KISA가 2024년 「ECH 적용 권고안(가이드)」 초안을 공개하여 정부·공공 서비스의 대응을 준비 중이다.

둘째, 「인증서 투명성(Certificate Transparency, CT)」의 확대 적용이다. RFC 6962로 표준화된 CT는 모든 발급 인증서를 공개 로그에 기록하여 무단 발급·악의적 CA를 사후 적발할 수 있게 한다. KISA의 「TLS 1.3 가이드라인」(2023)은 SCT(Signed Certificate Timestamp) 포함을 의무화하였고, KICA·KOSCOM의 발급 파이프라인은 SCT를 자동 포함한다. 2024년 시점 한국 공공 사이트의 약 96퍼센트가 CT 준수 인증서를 사용하고 있다.

셋째, 「암호 민첩성(crypto agility)」의 표준화이다. 양자컴퓨터 위협에 대응하기 위해 NIST는 2024년 8월 「FIPS 203(ML-KEM)」, 「FIPS 204(ML-DSA)」, 「FIPS 205(SLH-DSA)」 세 가지 양자 내성 암호 표준을 정식 공포하였다. 본 표준들은 점진적으로 TLS 키 교환(kyber768)과 디지털 서명에 적용되고 있으며, KISA·KCMVP·TTA가 한국 적용 부속서를 2025년 공포 예정이다. 카카오·NAVER·토스는 「하이브리드 키 교환」(X25519 + Kyber768)을 시범 운영 중이다.

9.1 시뮬레이터 패널 2 활용 가이드

본 장의 학습 효과를 높이기 위해, 시뮬레이터 패널 2에서 다음 다섯 가지 실습을 권장한다. 첫째, 다양한 ALPN 광고 조합을 입력하고 서버 응답을 관찰하라. 둘째, SNI 호스트명을 변경하면서 가상 호스트 라우팅 동작을 검증하라. 셋째, 「Accept-Language」 헤더의 q-가중치를 조정하면서 콘텐츠 협상 결과를 비교하라. 넷째, 「Alt-Svc」 헤더 캐시 동작을 통해 HTTP/3 폴백 흐름을 추적하라. 다섯째, 능력 협상의 「불가지 안전」 시나리오를 작성하고 옛 클라이언트 호환성을 확인하라.

본 다섯 실습은 한 주 분량의 작업으로 수행 가능하며, 완료 시 학습자는 프로토콜 협상의 운영 수준 이해에 도달한다. KISA의 「전자정부 SSL/TLS 진단기」 결과와 비교하여 자신의 학습 성과를 정량적으로 확인할 수 있다.