ECH

ECH(Encrypted Client Hello)는 TLS(Transport Layer Security) 프로토콜의 핸드셰이크 과정에서 클라이언트가 보내는 첫 번째 메시지인 Client Hello 메시지의 내용을 암호화하는 기술이다. 이 기술은 IETF(Internet Engineering Task Force)에서 표준화를 진행 중인 확장 프로토콜로, 기존 TLS 1.3에서 암호화되지 않은 채로 전송되던 핵심 정보를 보호하는 것을 목표로 한다.

Client Hello 메시지는 클라이언트가 접속하려는 서버의 도메인 이름(SNI, Server Name Indication)과 지원하는 암호화 스위트 목록 등을 포함한다. 이 정보는 중간자나 네트워크 관찰자가 사용자의 방문 사이트를 식별하거나, 특정 국가에서 인터넷 검열을 수행하는 데 악용될 수 있었다. ECH는 이러한 메타데이터를 암호화함으로써, 통신의 프라이버시와 보안을 한층 강화한다.

ECH의 동작은 서버가 공개적으로 배포하는 구성 정보에 의존한다. 클라이언트는 이 정보를 사용하여 Client Hello의 민감한 부분을 암호화하고, 서버는 이를 정확히 복호화하여 정상적인 핸드셰이크를 계속할 수 있다. 이 과정은 공개 키 암호 방식을 기반으로 한다.

이 기술은 이전에 제안된 ESNI(Encrypted SNI)의 개념을 발전시켜, SNI뿐만 아니라 Client Hello 메시지 전체의 더 많은 필드를 암호화 대상으로 포함한다. 주요 인터넷 브라우저 및 콘텐츠 전송 네트워크(CDN) 업체들이 실험적 지원을 시작하면서, 향후 웹 표준으로 자리 잡을 가능성을 보이고 있다.

ECH는 TLS 핸드셰이크 과정에서 클라이언트가 연결하려는 서버의 실제 도메인 이름(SNI)을 암호화하여 전송하는 기술이다. 기존 TLS에서는 SNI 필드가 평문으로 노출되어, 네트워크 관찰자가 사용자가 방문하는 웹사이트를 쉽게 식별할 수 있었다. ECH는 이 정보를 암호화함으로써 연결 초기 단계부터 프라이버시를 보호한다.

기술의 핵심은 공개 키 암호화를 활용하는 것이다. 서버는 ECH를 지원함을 나타내는 공개 키 구성(ECHConfig)을 미리 공개한다. 클라이언트(예: 웹 브라우저)는 이 공개 키를 사용하여 암호화된 SNI를 포함한 '내부' 핸드셰이크를 생성한다. 동시에, 서버의 CDN 제공자나 네트워크 운영자와 같은 중간자가 실제로 연결을 처리할 수 있도록, 일반적인 SNI를 포함한 '외부' 핸드셰이크도 함께 준비한다. 이 외부 핸드셰이크에는 암호화된 내부 핸드셰이크가 포함된다.

작동 방식은 다음과 같은 단계로 요약할 수 있다.

1. 클라이언트는 서버로부터 ECH 공개 키 구성(ECHConfig)을 받는다.

2. 연결 시, 클라이언트는 암호화된 실제 SNI(내부 핸드셰이크)와 이를 감싸는 외부 핸드셰이크를 생성하여 서버에 전송한다.

3. 외부 핸드셰이크를 수신한 엔터티(예: CDN)는 자신이 처리할 수 있는 경우 연결을 설정하고, 암호화된 내부 핸드셰이크는 최종 목적지 서버로 전달한다.

4. 최종 목적지 서버는 자신의 개인 키로 내부 핸드셰이크를 복호화하여 실제 SNI를 확인하고, 내부 핸드셰이크를 기반으로 최종적인 보안 연결을 완성한다.

이 과정은 TLS 1.3의 보안 핸드셰이크 프레임워크 내에서, 기존의 확장 메커니즘을 활용하여 구현된다. 따라서 핸드셰이크 자체의 암호화 강도나 성능에는 큰 영향을 미치지 않으면서, 메타데이터 보호 수준을 크게 향상시킨다.

ECH의 주요 목적은 인터넷 사용자의 프라이버시를 강화하고, 네트워크 수준에서의 감시 및 검열을 우회할 수 있는 능력을 제공하는 데 있다. 이는 TLS 핸드셰이크 과정에서 교환되는 서버 이름 표시 정보를 암호화함으로써 달성된다.

가장 중요한 목적은 프라이버시 보호이다. 기존 TLS에서는 클라이언트가 연결하려는 서버의 도메인 이름이 암호화되지 않은 상태로 네트워크 상에 노출된다. 이는 제3자가 사용자가 방문하는 웹사이트를 쉽게 식별할 수 있게 만든다. ECH는 이 SNI 정보를 암호화하여, 중간자나 네트워크 관찰자가 어떤 사이트에 접속하는지 알 수 없도록 한다. 이는 사용자의 검색 기록과 온라인 활동을 보호하는 데 기여한다.

또 다른 핵심 목적은 감시 및 검열 우회이다. 일부 국가나 네트워크 운영자는 특정 도메인 이름을 기반으로 트래픽을 차단하거나 감시한다. 암호화되지 않은 SNI는 이러한 차단의 쉬운 표적이 된다. ECH를 사용하면 차단 시스템이 트래픽의 목적지를 식별할 수 없어, 검열을 효과적으로 우회할 가능성을 높인다. 이는 정보의 자유로운 흐름을 보장하는 데 중요한 역할을 한다.

이러한 기술은 궁극적으로 엔드투엔드 암호화의 범위를 확장하여, 인터넷 프로토콜 스택의 더 많은 계층에서 사용자 데이터를 보호한다. 이는 사용자에게 더 높은 수준의 보안과 프라이버시를 제공하는 인터넷 생태계를 구축하는 데 기여한다.

TLS 확장으로 구현되는 ECH는 클라이언트와 서버 간의 핸드셰이크 과정에 통합되어 배포됩니다. 핵심은 클라이언트가 "내부" 서버 이름(실제 방문하려는 사이트)을 암호화하는 동시에, CDN이나 네트워크 중간 노드가 연결을 올바르게 라우팅할 수 있도록 "외부" 서버 이름(일반적으로 CDN 제공자의 도메인)을 평문으로 남겨두는 이중 메커니즘입니다. 이 구조는 기존 TLS 핸드셰이크와의 호환성을 유지하면서 배포 장벽을 낮추는 데 기여합니다.

배포 현황은 아직 초기 단계에 있으나, 주요 소프트웨어의 지원이 확대되고 있습니다. 다음 표는 주요 구현체의 지원 현황을 보여줍니다.

서버 측에서는 Cloudflare가 공개적으로 실험적 지원을 선도하고 있으며, 다른 주요 CDN 및 호스팅 업체들도 표준이 안정화됨에 따라 지원을 검토하고 있습니다. 클라이언트 측에서는 Mozilla Firefox가 가장 적극적으로 개발에 참여하고 있으며, 구글 크롬을 비롯한 다른 브라우저들도 표준화 과정을 주시하고 있습니다. 배포의 성공은 광범위한 클라이언트와 서버 양측의 채택에 달려 있으며, 이는 인터넷 엔지니어링 태스크 포스 내의 표준화 작업과 병행되어 진행되고 있습니다.

ECH는 프라이버시를 강화하지만, 몇 가지 보안상 고려해야 할 사항이 존재합니다. 가장 큰 우려는 인증서 투명성 로그와의 상호작용입니다. ECH는 클라이언트가 실제 방문하려는 서버의 이름을 암호화하므로, 로그 운영자는 해당 서버가 유효한 TLS 인증서를 소유했는지 사전에 확인할 수 없습니다. 이는 악의적인 인증서가 로그에 제출되고 게시될 가능성을 높일 수 있습니다[3].

또한, ECH의 성공적인 작동은 클라이언트와 서버 모두가 최신 프로토콜을 지원해야 합니다. 만약 호환성 문제나 구성 오류로 ECH 핸드셰이크가 실패하면, 클라이언트는 평문으로 된 SNI를 보내는 대체 핸드셰이크로 되돌아가야 합니다. 이 '후퇴' 과정 자체가 관찰자에게 연결 시도가 있었다는 정보를 노출시킬 수 있으며, 이는 일종의 부채널 정보 유출이 될 수 있습니다.

마지막으로, ECH는 SNI 암호화에 초점을 맞추고 있지만, TLS 핸드셰이크 중에 교환되는 다른 메타데이터(예: ALPN 확장)는 여전히 평문으로 노출될 수 있습니다. 이는 완전한 메타데이터 프라이버시를 달성하기 위해서는 ECH 외에 추가적인 프로토콜 개선이 필요함을 시사합니다.

ECH의 표준화 작업은 주로 IETF의 TLS 워킹 그룹에서 진행되었다. 핵심 사양은 초기에는 "ESNI"라는 이름으로 개발되다가, 더 포괄적인 설계로 발전하면서 "ECH"로 재명명되었다. 이 프로토콜은 현재 인터넷 표준 트랙 문서인 RFC 8879(ESNI)와 이를 대체할 RFC 9018(ECH)로 공식화되었다[4].

개발 현황은 다음과 같은 단계를 거쳐 왔다.

주요 브라우저 및 서비스 제공업체들은 이 표준을 점진적으로 채택하고 있다. 모질라 파이어폭스와 구글 크롬은 실험적 플래그 뒤에 ECH 지원을 도입했으며, 클라우드플레어는 자사의 네트워크에서 ECH를 배포한 주요 업체이다. 표준화 이후의 주요 개발 활동은 상호운용성 테스트, 성능 최적화, 그리고 DNS와 TLS 인프라에의 원활한 통합을 위한 작업에 집중되고 있다.

표준화 과정에서 역방향 호환성과 중간자 공격에 대한 저항성 강화가 중요한 논의 주제였다. 최종 RFC는 이러한 보안 고려사항을 반영하면서도 광범위한 배포를 가능하게 하는 실용적인 설계를 목표로 했다. 향후 개발 방향은 프로토콜을 인터넷 표준(Internet Standard)으로 승격시키고, 더 많은 CDN 제공자와 호스팅 서비스가 지원을 확대하도록 하는 데 초점이 맞춰져 있다.

ECH는 TLS 핸드셰이크 과정에서 서버 이름 표시(SNI)를 암호화하는 기술이다. 이와 유사한 목표를 가진 이전 기술인 ESNI(Encrypted Server Name Indication)와의 주요 차이점은 작동 계층과 구현 방식에 있다.

ESNI는 TLS 1.3 확장으로, 핸드셰이크 내의 ClientHello 메시지에 포함된 SNI만을 암호화했다. 반면, ECH는 더 포괄적인 접근법을 채택하여 전체 ClientHello 메시지를 암호화한다. 이는 핸드셰이크 초기 단계에서 교환되는 더 많은 정보(예: 지원하는 암호 제안 목록)를 보호함으로써 핑거프린팅 공격에 대한 저항성을 높인다. 기술적으로 ECH는 TLS 핸드셰이크를 두 단계로 나눈다. 첫 번째 '외부' 핸드셰이크는 암호화된 '내부' ClientHello를 전달할 수 있는 임시 연결을 설정하고, 두 번째 단계에서 실제 암호화된 연결이 협상된다.

다른 암호화 기술과 비교했을 때, ECH는 TLS 프로토콜 스택 내에서 종단 간 암호화를 제공하는 HTTPS와는 목적이 다르다. HTTPS는 애플리케이션 계층 데이터의 기밀성을 보장하지만, ECH는 연결 설정 과정 자체의 메타데이터를 보호한다. 또한, VPN이나 Tor 같은 터널링 기술이 전체 트래픽 경로를 숨기는 반면, ECH는 특정하게 SNI 정보 누출이라는 문제를 TLS 프로토콜 수준에서 해결한다. 이는 사용자에게 투명하게 동작하며 애플리케이션 수정이 필요 없다는 장점이 있다.

ECH는 강력한 프라이버시 보호 기능을 제공하지만, 기술적 복잡성과 배포 장벽으로 인해 논란과 비판에 직면해 있다. 가장 큰 우려는 중간자 공격을 완전히 방어하지 못할 수 있다는 점이다. 악의적인 DNS 서버나 네트워크 공격자가 클라이언트 헬로 패킷을 가로채고 조작하여 암호화되지 않은 레거시 Server Name Indication으로 연결을 강제할 수 있는 가능성이 지적된다[5]. 이 경우 사용자는 자신의 도메인 이름이 노출되었다는 사실을 인지하지 못할 수 있다.

표준화 및 상호운용성 과정에서도 어려움이 발생했다. 초기 버전인 ESNI는 단일 공개 키를 사용했으나, 이는 키 로테이션과 키 관리에 취약점으로 작용했다. 이를 해결하기 위해 ECH는 키 설정을 도입했지만, 이로 인해 DNS를 통한 키 배포 메커니즘이 복잡해지고, DNS 보안 확장의 채택 속도에 의존하게 되었다. 결과적으로, 모든 구성 요소(클라이언트, 서버, DNS)가 정확하게 설정되지 않으면 연결 실패가 빈번히 발생할 수 있어 사용자 경험을 해칠 수 있다.

또한, ECH가 국가 차원의 인터넷 검열을 효과적으로 우회할 수 있다는 점은 일부 국가와 기관으로부터 규제 압력을 받는 원인이 되었다. 이는 기술의 정치적, 사회적 영향력을 보여주는 사례이다. 일부 네트워크 운영자는 트래픽 모니터링과 네트워크 관리가 어려워질 것을 우려하기도 한다. 이러한 논란들은 기술의 순수한 이점과 실제 세계에서의 적용 가능성 사이에 존재하는 간극을 드러낸다.

• IETF - Encrypted Client Hello (ECH)

• Cloudflare - Encrypted Client Hello: the last puzzle piece to privacy

• Mozilla Security Blog - Encrypted Client Hello: a look under the hood

• The Chromium Projects - Encrypted Client Hello (ECH) deployment

• Wikipedia - Encrypted Client Hello

• Apple Developer - Supporting Encrypted Client Hello