ESNI

서버 이름 표시는 TLS 핸드셰이크 과정의 일부로, 클라이언트가 접속하려는 웹사이트의 호스트명을 평문으로 서버에 전송하는 확장 기능이다. 이는 하나의 IP 주소로 여러 개의 웹사이트를 호스팅하는 가상 호스팅 환경에서, 서버가 클라이언트가 요청한 정확한 사이트의 인증서를 제공하기 위해 필수적이다. 그러나 SNI 정보가 암호화되지 않은 채 전송되기 때문에, 네트워크 경로상의 제3자(예: 인터넷 서비스 제공자, 공공 와이파이 운영자)가 사용자가 방문하는 웹사이트의 도메인 이름을 쉽게 관찰할 수 있다.

이러한 SNI의 평문 노출은 사용자의 프라이버시에 심각한 문제를 야기한다. 제3자는 SNI 정보를 분석하여 사용자의 웹 브라우징 기록, 관심사, 심지어 특정 서비스(예: 뉴스 사이트, 건강 정보 포럼)에 대한 접속 패턴까지 추적할 수 있다. 또한, 일부 국가나 조직에서는 SNI 정보를 검사하여 특정 웹사이트에 대한 접속을 차단하는 데 활용하기도 한다. 이는 엔드투엔드 암호화가 적용된 HTTPS 통신의 본래 목적 중 하나인 콘텐츠 기밀성을 부분적으로 훼손하는 결과를 낳았다.

SNI의 한계를 요약하면 다음과 같다.

따라서 ESNI는 바로 이 SNI 정보를 암호화하여, 가상 호스팅의 기술적 필요성은 유지하면서도 사용자의 프라이버시를 강화하고 SNI 기반 차단을 더 어렵게 만드는 것을 핵심 목표로 개발되었다.

SNI 필드는 TLS 핸드셰이크 과정에서 평문으로 전송되기 때문에, 네트워크 경로상의 중간자(예: 인터넷 서비스 제공자, 공공 와이파이 운영자, 국가 차단 시스템)가 사용자가 접속하려는 웹사이트의 도메인 이름을 쉽게 확인할 수 있습니다. 이는 두 가지 주요 문제를 야기합니다.

첫째, 사용자의 프라이버시가 침해됩니다. 관찰자는 암호화된 트래픽의 내용은 볼 수 없지만, SNI를 통해 사용자의 방문 기록을 추적할 수 있습니다. 둘째, 이 정보는 특정 서비스나 웹사이트를 차단하는 데 악용될 수 있습니다. 차단 시스템은 평문 SNI를 검사하여 특정 도메인에 대한 연결을 차단할 수 있습니다. 이는 검열을 우회하는 HTTPS의 목적을 부분적으로 훼손합니다.

따라서 SNI 정보를 암호화하는 것은 사용자 프라이버시 보호와 검열 저항성 강화를 위한 논리적이고 필수적인 다음 단계입니다. TLS 1.3이 연결의 대부분을 암호화했음에도 남아 있는 주요 메타데이터 누출 경로를 제거함으로써, 종단 간 암호화의 원칙을 더욱 완벽하게 실현합니다.

ESNI의 핸드셰이크 과정은 기존 TLS 핸드셰이크를 확장하여, 클라이언트 헬로(Client Hello) 메시지 내에 포함되는 서버 이름 표시(SNI) 확장 필드를 암호화하는 방식으로 이루어진다. 이 과정은 TLS 1.3을 기반으로 하며, 사전에 DNS를 통해 공개키를 조회하는 단계가 선행된다.

핸드셰이크는 다음과 같은 단계로 진행된다.

1. 공개키 조회: 클라이언트는 접속하려는 도메인의 DNS 레코드를 조회할 때, 해당 도메인의 ESNI 공개키(ESNI_Keys)를 함께 받는다. 이 키는 TXT 레코드 형태로 배포된다.

2. 암호화된 SNI 생성: 클라이언트는 조회한 공개키를 사용하여 접속하려는 실제 도메인 이름(예: www.example.com)을 암호화한다. 이렇게 생성된 암호문을 Encrypted SNI(ESNI) 값이라고 한다.

3. Client Hello 전송: 클라이언트는 서버에 보내는 첫 핸드셰이크 메시지인 클라이언트 헬로에 두 개의 SNI 확장 필드를 포함시킨다.

* 첫 번째는 일반적인(평문) SNI 확장으로, 여기에는 서버의 IP 주소에 해당하는 도메인(예: CDN 업체의 도메인)을 기입한다. 이는 하위 호환성을 위해 필요하다.

* 두 번째는 새로운 encrypted_server_name 확장으로, 앞서 생성한 ESNI 암호문을 담는다.

4. 복호화 및 세션 확립: 올바른 개인키를 가진 서버만이 encrypted_server_name 확장 필드의 내용을 복호화하여 클라이언트가 실제로 접속하려는 도메인을 알 수 있다. 이후 나머지 TLS 1.3 핸드셰이크는 정상적으로 진행되어 암호화된 연결이 수립된다.

이 과정을 표로 요약하면 다음과 같다.

결과적으로 네트워크 중간 관찰자는 클라이언트 헬로 메시지에서 평문 SNI 확장만 볼 수 있으며, 클라이언트가 최종적으로 어떤 사이트에 접속하는지는 알 수 없게 된다.

ESNI의 핵심은 TLS 핸드셰이크 과정에서 서버 이름 표시(SNI) 필드를 암호화하는 데 있다. 이 암호화를 가능하게 하는 키 교환 및 암호화 메커니즘은 TLS 1.3 프로토콜과 공개 키 암호 방식에 기반한다.

서버는 먼저 자신의 공개 키를 DNS 레코드(TXT 레코드)에 게시한다. 이 공개 키는 특정 서버 이름(예: example.com)에 대한 SNI 암호화 키로 사용된다. 클라이언트(예: 웹 브라우저)는 해당 도메인에 접속하기 전에 DNS 조회를 수행하며, 이 과정에서 암호화된 SNI에 사용할 공개 키를 함께 획득한다. 이후 실제 TLS 핸드셰이크를 시작할 때, 클라이언트는 획득한 공개 키를 이용해 SNI 값을 암호화하여 ClientHello 메시지 내에 포함시킨다.

암호화된 SNI 필드는 오직 해당 공개 키를 소유한 서버만이 대응되는 개인 키로 복호화할 수 있다. 따라서 중간 관찰자는 ClientHello 메시지를 볼 수 있더라도 사용자가 접속하려는 실제 서버의 도메인 이름을 알 수 없다. 핸드셰이크의 나머지 부분, 즉 대칭 키 협상과 애플리케이션 데이터 암호화는 기존 TLS 1.3의 표준 절차를 그대로 따른다.

ESNI의 가장 핵심적인 목표는 SNI 필드를 암호화함으로써 사용자의 연결 프라이버시를 강화하는 것이다. 기존 TLS 핸드셰이크에서 평문으로 노출되던 SNI 정보는, 사용자가 방문하려는 웹사이트의 도메인 이름을 네트워크 관찰자(예: ISP, 공공 와이파이 운영자, 국가 차단 시스템)에게 그대로 드러냈다. ESNI는 이 정보를 암호화하여, 제3자가 패킷 스니핑을 통해 특정 사용자가 어떤 사이트에 접속하는지를 쉽게 알아낼 수 없도록 한다.

이를 통해 얻는 프라이버시 보호 효과는 다층적이다. 첫째, 단순한 웹 서핑 이력조차 감시로부터 보호받을 수 있다. 둘째, 국가나 조직이 특정 사이트를 SNI 필터링 방식으로 차단하는 것을 기술적으로 어렵게 만든다. 셋째, 공용 네트워크에서의 활동이 상대적으로 안전해진다. 그러나 이 보호는 완전하지 않다. 여전히 접속하는 서버의 IP 주소는 평문으로 노출되며, DNS 쿼리가 암호화되지 않았다면 이 정보도 유출될 수 있다. 따라서 ESNI는 DoH나 DoT 같은 암호화된 DNS와 함께 사용될 때 가장 효과적인 프라이버시 보호를 제공한다.

ESNI의 프라이버시 메커니즘은 사용자에게 선택권을 제공하지 않는 것이 특징이다. 일단 서버와 클라이언트(브라우저)가 모두 ESNI를 지원하면, 지원되는 연결에서는 항상 SNI 암호화가 적용된다. 이는 사용자의 실수나 무관심으로 인해 프라이버시 설정이 꺼지는 것을 방지하는 설계이다. 다만, 이 자동화된 적용은 네트워크 운영자나 정부의 입장에서는 트래픽 관리와 감시에 장애물로 작용할 수 있어 논란의 원인이 되기도 했다.

ESNI는 기존 TLS 핸드셰이크와의 호환성을 유지하면서 설계되었다. 핵심 암호화 메커니즘은 TLS 1.3 확장을 통해 구현되므로, TLS 1.3을 지원하는 클라이언트와 서버는 추가적인 프로토콜 변경 없이 ESNI를 사용할 수 있다. 이는 네트워크 중간 장비나 구형 인프라에 대한 광범위한 수정을 요구하지 않음을 의미한다.

그러나 완전한 기능을 위해서는 몇 가지 선행 조건이 필요하다. 서버 측에서는 TLS 1.3과 ESNI 확장을 지원해야 하며, 공개적으로 접근 가능한 DNS 레코드에 서버의 공개 키를 TXT 레코드 형태로 게시해야 한다. 클라이언트(예: 웹 브라우저)는 이 DNS 레코드를 조회하여 암호화된 SNI를 생성할 수 있는 키를 획득한다. 따라서 ESNI의 호환성은 TLS 1.3, DNS 조회, 그리고 해당 암호화 스위트에 대한 지원에 종속된다.

일부 구형 네트워크 보안 장비나 감시 장치가 암호화된 SNI 필드를 인식하지 못해 연결 문제를 일으킬 가능성이 있다. 또한, DNS를 통한 공개 키 배포 방식은 키 관리와 신뢰 체인에 새로운 복잡성을 추가한다. 전반적으로 ESNI는 현대적인 TLS 1.3 생태계 내에서 점진적으로 도입될 수 있도록 설계된 하위 호환성 확장이다.

ESNI를 지원하는 주요 웹 브라우저는 다음과 같다. 초기 지원은 Mozilla Firefox와 Google Chrome에서 시작되었으며, 이후 다른 브라우저들도 실험적 지원을 도입하거나 검토하였다.

지원 브라우저는 TLS 1.3과 DNS over HTTPS를 함께 사용해야 ESNI의 효과를 발휘할 수 있다. 이는 클라이언트가 암호화된 SNI를 보내기 전에, 먼저 DoH를 통해 해당 서버의 공개 키를 포함한 DNS 레코드를 안전하게 조회해야 하기 때문이다. 대부분의 구현은 Cloudflare 등 초기 ESNI를 제공한 CDN 업체의 테스트 서버와 연동하여 개발되었다.

브라우저 지원은 ESNI의 후속 규격인 ECH로의 전환과 함께 변화하였다. IETF 표준화 과정에서 ESNI는 ECH로 진화했고, 이에 따라 Firefox와 Chrome은 ESNI 지원을 중단하고 ECH 실험을 시작했다. 따라서 ESNI에 대한 브라우저 지원은 일시적인 실험 단계에 머물렀다고 볼 수 있다.

서버 측에서 ESNI를 구현하려면 TLS 서버가 ESNI 확장을 지원하고, 공개적으로 접근 가능한 DNS 서버에 암호화된 SNI 정보를 담은 특별한 레코드(TXT 레코드 또는 이후 규격화된 HTTPS 레코드)를 게시해야 합니다. 이 레코드는 서버의 공개 키와 암호화에 사용할 수 있는 암호 스위트 정보를 포함합니다.

주요 웹 서버 소프트웨어의 구현 상황은 다음과 같습니다.

서버 운영자는 지원 소프트웨어를 구성한 후, 도메인의 DNS에 ESNI 키 레코드를 게시해야 클라이언트가 이를 조회하여 사용할 수 있습니다. 이 과정은 일반적인 인증서 관리와는 별개로 진행됩니다. 초기 구현은 주로 CDN 업체와 대규모 호스팅 서비스를 중심으로 이루어졌으며, 일반적인 공유 호스팅 환경에서는 널리 보급되지 않았습니다. 이는 서버와 DNS 설정 모두에 변경이 필요하기 때문입니다.

ESNI는 SNI 필드를 암호화함으로써, 네트워크 중간에서 특정 웹사이트에 대한 사용자의 접속 시도를 관찰하는 것을 어렵게 만든다. 이전의 TLS 핸드셰이크에서는 암호화가 시작되기 전에 평문으로 전송되는 SNI 정보를 통해 제3자(예: ISP, 공공 와이파이 운영자, 국가 차원의 감시 기관)가 사용자가 방문하려는 웹사이트의 도메인 이름을 쉽게 확인할 수 있었다. ESNI는 이러한 메타데이터를 암호화하여, 외부 관찰자에게는 사용자가 특정 사이트에 접속하는지 여부를 판단하기 어렵게 한다.

이 기술은 특히 검열이나 감시가 심한 지역에서 사용자의 인터넷 프라이버시를 강화하는 의미를 가진다. 관찰자는 여전히 접속 대상 서버의 IP 주소를 알 수 있지만, 하나의 IP 주소 뒤에 여러 웹사이트가 호스팅되는 가상 호스팅이 일반화된 현대 인터넷 환경에서는 암호화된 SNI 없이는 정확한 사이트를 특정하기 힘들다. 이는 사용자의 온라인 활동 프로필을 수집하는 행위에 대한 기술적 장벽을 높인다.

그러나 ESNI가 감시를 완전히 불가능하게 만들지는 않는다. 트래픽 분석이나 심층 패킷 검사(DPI)를 통해 암호화된 트래픽의 패턴, 타이밍, 패킷 크기 등을 추적하여 방문 사이트를 유추하는 공격은 여전히 가능하다. 또한, DNS 쿼리가 별도로 암호화(DoH 또는 DoT)되지 않았다면, 초기 도메인 이름 조회 단계에서 정보가 노출될 수 있다.

따라서 ESNI는 사용자 메타데이터 보호의 중요한 한 단계를 제공하지만, 포괄적인 프라이버시를 위해서는 암호화 DNS, Tor, VPN 등 다른 기술과의 결합이 필요하다.

ESNI는 SNI 필드를 암호화하여 사용자가 방문하는 웹사이트의 도메인 이름을 제3자가 엿보는 것을 방지하도록 설계되었다. 그러나 이 기술적 특성 때문에, 일부 국가나 조직이 특정 웹사이트에 대한 접근을 SNI 필드 검사를 통해 차단하는 기존 방식을 무력화할 수 있다는 점에서 논란을 일으켰다.

국가별 인터넷 검열 시스템은 전통적으로 평문으로 전송되는 SNI 정보를 확인하여 특정 도메인(예: 정치적 반대 사이트, 특정 미디어, 성인 콘텐츠 사이트 등)으로의 접속을 차단해왔다. ESNI가 이 정보를 암호화하면, 네트워크 중간에서 차단 장비가 사용자가 어느 사이트에 접속하려는지 식별할 수 없게 되어, 기존 차단 방식이 실효성을 잃을 수 있다. 이는 사용자 프라이버시 향상이라는 측면에서는 긍정적이지만, 국가가 법률에 따라 합법적으로 콘텐츠를 규제하려는 정책 목표와 충돌할 수 있다.

이에 따라 일부 국가에서는 ESNI와 같은 암호화 기술의 광범위한 채용을 인터넷 주권이나 사이버 보안에 대한 위협으로 간주하기도 했다. 반면, 인권 옹호 단체와 기술 커뮤니티는 ESNI가 기본적인 디지털 권리와 표현의 자유를 보호하는 필수 도구라고 주장한다. 이 논란은 기술의 중립성과 사회적 통제의 균형에 대한 근본적인 질문을 제기한다.

결국 이 논란은 ESNI와 그 후속 기술인 ECH의 배포 속도와 범위에 영향을 미쳤다. 일부 인터넷 서비스 제공자나 국가에서는 해당 기술을 지원하지 않거나 차단하는 조치를 고려하도록 만들었다.

ESNI는 SNI 정보를 암호화하여 도청과 트래픽 분석으로부터 사용자를 보호하지만, 몇 가지 기술적 한계점을 지니고 있다.

첫째, ESNI는 핸드셰이크 과정에서 교환되는 SNI 정보만을 암호화한다. 연결이 설정된 후 전송되는 실제 데이터의 IP 헤더와 TCP 헤더는 여전히 평문으로 노출된다. 이는 통신 상대의 IP 주소와 포트 번호가 외부에 드러남을 의미하며, 이를 통해 관찰자는 사용자가 어떤 서버와 통신하는지 여전히 추적할 수 있다. 또한, 패킷 크기와 통신 타이밍과 같은 메타데이터 분석을 통한 웹사이트 핑거프린팅 공격을 완전히 차단하지는 못한다.

둘째, ESNI의 효과적인 동작을 위해서는 클라이언트가 접속하려는 서버의 공개키를 미리 알고 있어야 한다. 이 키는 일반적으로 해당 서버의 DNS 레코드(TXT 레코드 또는 새로운 HTTPS 레코드)를 통해 발행된다. 이는 다음과 같은 문제를 야기할 수 있다.

마지막으로, ESNI는 TLS 1.3 프로토콜과 강하게 결합되어 설계되었다. 따라서 TLS 1.3을 지원하지 않는 오래된 클라이언트나 서버와는 호환되지 않는다. 또한, 네트워크 중간에서 DPI를 수행하는 일부 보안 장비나 감시 솔루션은 암호화된 SNI를 처리하지 못해 연결 문제를 일으킬 수 있다. 이러한 기술적 한계점들을 해결하고 프라이버시 보호를 더욱 강화하기 위한 노력의 일환으로, IETF에서는 ESNI의 후속 규격인 ECH를 개발하고 있다.

ESNI는 SNI 암호화를 위한 중요한 첫걸음이었지만, 기술적 한계가 존재했다. 가장 큰 문제는 핸드셰이크 과정에서 여전히 평문으로 전송되는 정보가 많아, 서버의 인증서와 연결된 IP 주소를 통해 접속하려는 사이트를 추론할 수 있는 가능성을 완전히 차단하지 못했다는 점이다. 이는 진정한 연결 프라이버시를 달성하기에는 불충분했다.

이러한 한계를 극복하기 위해 IETF는 ESNI의 후속 프로토콜인 암호화된 클라이언트 헬로(ECH)를 개발했다. ECH는 핸드셰이크 과정에서 암호화되는 정보의 범위를 크게 확장한다. ESNI가 SNI 필드만 암호화했다면, ECH는 서버의 공개 키와 연결된 전체 서버 이름을 포함하여 핸드셰이크 초기의 더 많은 메타데이터를 암호화한다. 이는 관찰자가 어떤 사이트에 접속하는지 추측하기 훨씬 더 어렵게 만든다.

ECH의 핵심 메커니즘은 "외부"와 "내부"의 이중 레이어 핸드셰이크를 사용하는 것이다. 클라이언트는 먼저 암호화되지 않은 "외부" SNI(예: CDN 제공자의 도메인)를 사용하여 중간 프록시 서버나 CDN에 연결한다. 그런 다음, 실제 목적지 서버(예: 웹사이트 본사 서버)의 이름을 포함한 "내부" 핸드셰이크 전체를 암호화하여 전송한다. 외부 엔터티는 내부의 실제 목적지를 알 수 없게 된다.

ECH는 ESNI의 개념을 발전시켜, 단순한 정보 은닉을 넘어서는 더 강력한 연결 프라이버시를 제공하는 것을 목표로 한다. 2023년부터 주요 브라우저와 CDN 업체들은 ESNI 지원을 중단하고 ECH 실험 및 배포로 전환하고 있다. 이는 TLS 프로토콜 진화의 자연스러운 과정으로, 지속적인 보안과 프라이버시 표준의 강화를 보여준다.