요약

  • ECH는 공개ClientHelloOuter안에 비공개ClientHelloInner를 암호화하여 SNI와 기타 민감한 핸드셰이크 필드를 일반적인 경로상 검사로부터 보호한다.
  • 그 프라이버시 결과는 단순한 암호학이 아니라 운영적이다. DNS가 최신 구성을 전달해야 하고, 클라이언트 대면 서버는 키와 재시도를 관리해야 하며, 수많은 오리진이 유용한 익명성 집합을 형성할 만큼 충분히 비슷하게 보여야 한다.
  • ECH는 DNS 질의, IP 주소 또는 모든 트래픽 분석 신호를 숨기지 않는다. 운영자를 위한 결정적 판단 기준은 zone에ech필드가 존재하는지가 아니라, 전체 체인이 조용한 다운그레이드 없이 동작하는지 여부다.

하나의 연결, 두 개의 인사말

패킷은 그럴듯한 외부 식별자를 담은 채 공개 TLS 전면도어에 도달한다. 그 안에는 클라이언트가 실제로 원하는 이름을 담은 두 번째 hello가 들어 있다. 클라이언트 대면 서버는 그 내부 메시지를 열어 올바른 백엔드로 라우팅할 수 있고, 접속 경로상의 관찰자는 비공개 서버 이름이 아니라 공개 봉투만 본다.

이 메커니즘은 TLS 핸드셰이크의 순서가 남긴 노출을 수선한다.server_name확장은 클라이언트가 인프라를 공유하는 여러 서비스 중 하나를 선택할 수 있도록 설계되었다. 이는 첫 번째 TLS 메시지인ClientHello에 들어 있다. TLS 1.3은 이후 대부분을 암호화하지만, 초기 라우팅에 필요한 이름은 계속 노출되어 있었다.RFC 6066은 원래 확장을 정의하고,RFC 8446은 여전히ClientHello로 시작하는 TLS 1.3 핸드셰이크를 정의한다.

2026년 3월 IETF Standards Track으로 발표된RFC 9849는 이 인사말을 바꾼다. 클라이언트는 진짜 SNI와 잠재적으로 ALPN 목록을 포함한 민감한 값을 담은ClientHelloInner를 만든다. 클라이언트는ECHConfig의 공개 키로 HPKE를 사용해 내부 메시지를 암호화한다. 그리고 공개 값을 담은ClientHelloOuter와 봉인된 내부 메시지를 운반하는encrypted_client_hello확장을 전송한다.

외부 hello는 보통의 패킷 위에 덧칠한 위장이 아니다. 이 구성의 인증된 부분이다. 전면 서버는 ECH를 수락하여 내부 hello를 처리하거나 전달하거나, ECH를 거부하고 외부 hello로 계속할 수 있다. 어느 경로가 발생했는지는 클라이언트가 판단한다. ECH를 제안했지만 거부된 그 연결은 애플리케이션 데이터에 사용되지 않는다. 거부는 최신 구성을 얻고 다시 시도하는 통제된 경로를 만든다.

전면도어가 보안 설계의 일부가 된다

RFC 9849는 두 가지 토폴로지를 지원한다. 공유 모드에서는 클라이언트 대면 서버와 TLS 종단이 같은 시스템이다. 분리 모드에서는 공개 전면이 내부 hello를 열어 별도의 백엔드로 중계하고, 그 백엔드가 연결을 종단한다. 따라서 전면은 보호된 애플리케이션 스트림의 종단이 되지 않으면서도 라우팅에 필요한 만큼은 학습할 수 있다.

이 분리는 기술적으로 정밀하고 제도적으로도 중요하다. DNS 게시자는 공개 이름을 승인하고 키 구성을 배포한다. 클라이언트는 ECH를 제안할지 선택한다. 전면은 대응하는 비공개 키를 보유하고 어느 백엔드가 내부 hello를 받을지 결정한다. 백엔드는 TLS 트랜스크립트의 일부로서 수락을 확인한다. 프라이버시는 이들의 합의로 만들어지며, 어느 한쪽도 결과 전체를 단독으로 만들어낼 수 없다.

ECHConfig는 공개 키 이상을 담는다. 구성 식별자, 지원되는 암호학 매개변수, 공개 이름, 패딩에 사용되는 입력도 포함된다. 클라이언트 대면 서버는 최신 구성과 클라이언트 캐시에 남아 있을 수 있는 이전 구성을 함께 유지해야 한다. 키를 빠르게 교체하면 키 유출 시 노출 창을 줄일 수 있지만, 낡은 클라이언트의 재시도를 유발할 수도 있다. 많은 키를 유지하면 시험 복호화 부담이 늘어난다. RFC는 메커니즘을 제공하지만 모든 배포에 정확한 교체 주기를 하나로 선언하지는 않는다.

TLS가 보호하기 전에 DNS가 지시를 운반한다

클라이언트는 첫 번째 TLS 메시지를 보내기 전에 구성이 필요하다. 그래서RFC 9848은RFC 9460의 DNS 서비스 바인딩 시스템을 위한ech서비스 매개변수를 정의한다. SVCB 및 HTTPS 레코드는 클라이언트에게 어떤 대체 엔드포인트를 사용할지, 어떤 연결 매개변수가 적용되는지 알려줄 수 있다. ECH 매개변수는 그 엔드포인트의 구성을 운반한다.

이것이 이 프로토콜에서 가장 중요한 인계 지점이다. TLS 내부의 프라이버시 기능이 이제 TLS 밖에서 전달되는 정보에 의존한다. 중간자가 클라이언트가 SVCB 또는 HTTPS 응답을 학습하지 못하게 하면, 클라이언트는 ECH가 구성되어 있다는 사실 자체를 모를 수 있다. RFC 9848은 ECH 지원 엔드포인트와 비지원 엔드포인트가 섞인 RRSet이 차단형 다운그레이드를 허용한다고 경고한다. 공격자는 보호된 대체 경로에 도달하지 못하게 만들고 보호되지 않은 경로만 남길 수 있다.

보안 리졸버 전송은 로컬 관찰자에 대한 방어에 도움이 되고, 클라이언트가 엄격하게 적용하면 검증이 데이터 무결성을 보호할 수 있다. 그러나 어느 쪽도 재귀 리졸버가 질의를 모르게 만들지는 않는다. ECH는 TLS hello 안의 비공개 이름을 보호하지만, DNS 질문에 답하는 리졸버에게 그 이름을 감추지는 않는다. 목적지 IP 주소도 지우지 않는다. 이 한계들은 낙관적 마케팅으로 메워야 할 결함이 아니라 설계 기록의 일부다.

프라이버시에는 무리처럼 행동하는 무리가 필요하다

ECH의 명시된 핸드셰이크 프라이버시 목표는 익명성 집합이다. 많은 서버 이름이 하나의 클라이언트 대면 서버를 공유하고, 공통 구성을 사용하고, 충분히 일관된 공개 행동을 보인다면, 관찰자는 hello만으로 어느 구성원이 연결을 받았는지 식별할 수 없어야 한다. 공급자가 이름마다 서로 다른 구성을 할당하면 집합은 하나로 무너질 수 있다.

키를 바꾸지 않고도 같은 일이 일어날 수 있다. 한 백엔드는 독특한 공개 암호 스위트 선호를 노출할 수 있다. 다른 백엔드는 확장 순서를 다르게 하거나, 레코드를 다르게 나누거나, 고유한 모양의 재시도 쿠키를 반환할 수 있다. 클라이언트 대면 시스템이 한 클러스터를 다른 클러스터보다 먼저 교체할 수도 있다. 암호화는 내부 값을 숨기면서 배포가 실루엣으로 그 값을 식별하게 할 수 있다.

그래서 “ECH 사용 중”은 불완전한 상태 표시다. 유용한 질문은 실제로 몇 개의 이름이 구성을 공유하는지, 이들의 외부 핸드셰이크가 비교 가능하게 유지되는지, 재시도 쿠키와 키 식별자가 어떻게 행동하는지, 그리고 분리된 전면을 통과하는 타이밍이 클라이언트 측을 특정 백엔드와 연결하는지 여부다. 이것들은 제어판의 체크박스가 아니라 시스템에 대한 측정이다.

실패는 폴백 동의와 다르게 보여야 한다

ECH는 자신이 바꾸려는 인터넷을 견뎌야 한다. GREASE ECH는 클라이언트가 사용 가능한 구성이 없을 때에도 그럴듯해 보이는 확장을 보내게 한다. 그 목적은 낯선 확장을 잘못 처리하는 구현을 드러내고, 진짜 ECH가 wire상 유일한 특이한 모양이 되지 않도록 하는 것이다.

그리스(greasing)는 진단도 복잡하게 만든다. 제안된 값을 복호화하지 못한 전면은 zone이 깨졌다고 단정할 수 없다. GREASE를 보고 있을 수도 있기 때문이다. 대신 RFC 9849는 서버에 최신 재시도 구성을 제공하고, 운영자가 셀 수 있는ech_required알림을 정의한다. 두 번의 호환 불가능한 재시도는 단일 복호화 실패보다 일관되지 않은 배포의 더 강한 신호다.

이 구별이 중요하다. 관용적인 외부 핸드셰이크는 상호운용성에 필요하지만, 클라이언트가 실패한 프라이버시를 겉보기에 성공한 보호 세션으로 바꿔서는 안 된다. ECH 거부는 클라이언트에게 의도적으로 가시적이며 애플리케이션 데이터에 사용할 수 없다. ECH가 구성되지 않았거나 제안되지 않은 경우에는 보통의 연결이 여전히 진행될 수 있지만, 그것은 “ECH가 약속되었고 조용히 잃어버렸다”와는 다른 상태다.

RFC가 증명하는 것과 열어 두는 것

확정된 기록은 메시지 형식, 행위자 역할, 재시도 논리, DNS 바인딩, 명시된 위협 모델을 증명한다. RFC 9849가 Standards Track임을 증명한다. 그러나 특정 브라우저가 ECH를 제공한다거나, 리졸버가 매개변수를 전달했다거나, 접속 네트워크가 그것을 건드리지 않았다거나, 공급자가 큰 익명성 집합을 만들었다는 것은 증명하지 않는다.

또한 일상적 의미의 익명성을 증명하지 않는다. 네트워크 관찰자는 여전히 공급자의 주소를 볼 수 있다. 리졸버는 여전히 질의를 볼 수 있다. 트래픽 상관, 이전 연결, 공개 행동이 여전히 목적지를 좁힐 수 있다. ECH는 더 넓은 관찰 환경 안에서 정의된 핸드셰이크 노출을 보호한다.

출처