ECH가 활성화되었지만 SNI가 여전히 보입니다: 2026년에 어떻게 확인하나요?

```html

ECH — 사이트 이름의 암호화는 TLS 핸드셰이크에서 2026년 3월에 표준으로 인정받았습니다 (RFC 9849, Standards Track). Firefox와 Chrome은 기본적으로 이를 포함하고 있으며, Cloudflare는 거의 모든 고객에게 키를 배포합니다. 그러나 대부분의 사용자에게 ECH는 조용히 작동하지 않습니다: 브라우저는 일반 핸드셰이크로 돌아가고, 제공자는 여전히 사용자가 어디로 가는지 볼 수 있습니다.

아래는 1분 만에 SNI가 암호화되어 있는지 확인하는 방법, 왜 대부분의 경우 암호화되지 않는지, 그리고 ECH가 원칙적으로 쓸모없는 시나리오에 대해 설명합니다 (스포일러: 안티탐지 및 파싱에는 거의 항상 쓸모가 없습니다).

ECH가 정확히 무엇을 숨기는가 — 그리고 무엇을 숨기지 않는가

일반 TLS 1.3에서는 첫 번째 메시지인 ClientHello를 제외한 모든 것이 암호화됩니다. 이 메시지에는 연결하려는 도메인이 포함된 SNI 필드가 평문으로 포함되어 있습니다. 대부분의 필터링 시스템은 SNI를 기반으로 작동합니다: IP는 CDN 뒤에 있는 수천 개의 사이트 중 하나에 불과하며, 도메인은 보입니다.

ECH는 ClientHello를 두 부분으로 나눕니다:

ClientHelloOuter — 공개적으로 전송되지만, 위장된 도메인으로 이루어져 있습니다. Cloudflare의 경우 cloudflare-ech.com입니다.
ClientHelloInner — 실제 도메인, ALPN 및 암호 목록이 서버의 공개 키로 암호화되어 있습니다.

이 암호화를 위한 키는 브라우저가 연결에서 가져오는 것이 아니라 DNS에서 가져옵니다 — HTTPS 레코드 (유형 65), 매개변수 ech=에서. 여기서 잊지 말아야 할 주요 결과는: 암호화된 DNS 없이는 ECH가 불가능합니다. DNS 요청이 열린 UDP/53으로 전송되면, 관찰자는 핸드셰이크 전에 도메인 이름을 볼 수 있으며, 필터링 리졸버는 응답에서 ech= 매개변수를 잘라낼 수 있습니다 — 그러면 ECH는 활성화되지 않습니다.

ECH가 전혀 숨기지 않는 것들:

목적지 IP 주소 — 항상 보입니다;
트래픽의 양과 타이밍;
클라이언트의 TLS 지문 (JA3/JA4) — 암호 및 확장 세트는 공개 부분에 남아 있습니다;
사이트에 대한 당신 — 서버는 복호화 후 이전에 보았던 모든 것을 볼 수 있습니다.

마지막 항목은 ECH가 안티봇 시스템 우회와 관련이 없는 이유입니다. Cloudflare, DataDome 및 Akamai는 서버 측에서 작동합니다: SNI가 전송 중에 암호화되었는지 여부는 중요하지 않습니다. 자동화 중에 발각되지 않는 것이 목표라면, TLS 지문 자체를 변경하는 완전히 다른 레이어가 작동합니다. 이는 curl-cffi를 통한 JA4 지문 우회에 대한 자료에서 다룬 내용입니다.

검사 #1: 지금 ECH가 작동하는지 확인하기 (10초)

브라우저에서 다음을 엽니다:

https://crypto.cloudflare.com/cdn-cgi/trace

sni=라는 줄을 찾습니다. 두 가지 경우가 가능합니다:

sni=encrypted — ECH가 작동하고 있으며, 사이트 이름이 전송 중에 숨겨져 있습니다;
sni=plaintext — ECH가 적용되지 않았으며, 도메인이 평문으로 전송되었습니다.

터미널에서 curl을 사용한 동일한 주소는 항상 sni=plaintext를 반환합니다 — 일반적인 curl은 ECH를 지원하지 않으며, 이는 "비활성화됨"을 나타내는 유용한 지표입니다.

검사 #2: 도메인에 ECH 키가 있는지 확인하기 (dig, 브라우저 없이)

도메인에 ech= 매개변수가 있는 HTTPS 레코드가 DNS에 있어야 ECH가 활성화됩니다. 원시 레코드를 확인합니다:

dig +short TYPE65 example.com @1.1.1.1

응답에서 FE0D 바이트를 찾습니다 — 이는 ECH 확장 코드이며, 그 뒤에 ECHConfig가 있습니다. 실용적인 예로, 자료 준비 시점에서 crypto.cloudflare.com와 우리의 도메인 proxycove.com의 레코드는 133–136 바이트 길이로 FE0D와 위장된 이름 cloudflare-ech.com을 16진수 형태로 포함하고 있습니다. 그러나 cloudflare.com 자체의 레코드는 짧고 61 바이트입니다: ALPN 및 IP 힌트만 포함되어 있으며, ECH는 없습니다. 즉, Cloudflare의 인프라 내에서도 ECH는 모든 도메인에 배포되지 않으므로 특정 사이트에 ECH가 없는 경우 놀라지 마십시오.

만약 dig가 ignoring invalid type HTTPS라는 오류를 발생시키면 — 이는 오래된 버전의 유틸리티를 사용하고 있는 것이므로, 위 명령에서와 같이 숫자 형식 TYPE65를 사용하십시오.

왜 ECH가 활성화되지 않는가: 다섯 가지 이유

암호화된 DNS가 비활성화되어 있습니다. DoH가 없으면 브라우저는 신뢰할 수 있는 형태로 ECHConfig를 받을 수 없습니다. Firefox: 설정 → 개인정보 보호 → HTTPS를 통한 DNS에서 "향상된" 또는 "최대 보호" 모드로 설정합니다. Chrome: 설정 → 보안 → 안전한 DNS 사용.
도메인에 ech=가 포함된 HTTPS 레코드가 없습니다. — 위 블록의 명령으로 확인합니다. 이는 귀하의 통제 밖에 있으며, 이는 사이트 소유자와 그의 CDN의 결정입니다.
리졸버가 매개변수를 잘라냅니다. 기업 및 제공자 DNS 서버는 기본적으로 ech= 없이 HTTPS 레코드를 반환할 수 있습니다. 공개 리졸버(@1.1.1.1)에 직접 요청하여 시스템 응답과 비교해 보십시오.
브라우저 플래그가 초기화되었습니다. Firefox에서는 network.dns.echconfig.enabled와 network.dns.http3_echconfig.enabled가 about:config에서 응답하며 — 둘 다 true여야 합니다.
중간에 검사하는 게이트웨이가 있습니다. 이에 대한 내용은 다음 섹션에서 다룹니다.

ECH를 해킹하는 방법: 두 가지 다른 방식

기업 방화벽: 조용한 저하

네트워크 장비 공급업체들은 ECH에 대한 준비된 레시피를 출시했습니다 — 트래픽의 가시성을 잃는 것을 원하지 않기 때문입니다. 예를 들어 Cisco는 애플리케이션 데이터베이스 VDB 416(2025년 10월)부터 "ECH 서버"를 별도의 애플리케이션으로 정의하고 두 가지 접근 방식을 제안합니다: 인증서를 재생성하여 연결을 가로채거나 ClientHello에서 encrypted_client_hello 확장을 잘라내는 것, 또는 DNS 레벨에서 간단하게 작동하여 ECH 도메인에 대한 HTTPS 레코드를 차단하고 DoH/DoT/DoQ를 잘라내며, use-application-dns.net의 캐너리 도메인을 차단하고 DNS를 기업 서버에만 허용합니다.

첫 번째 방식의 교활함은 차단처럼 보이지 않는다는 것입니다. 서버가 ECH 확장을 발견하지 못하면 정상적으로 응답하며, 클라이언트는 ECH가 "안전하게 비활성화됨"으로 간주하고 열린 SNI로 다시 연결합니다. 사이트가 열리고 오류가 없지만, 도메인 이름은 게이트웨이 로그에 기록됩니다.

국가 수준: 연결이 단순히 죽습니다

러시아의 예는 그 정확성으로 주목할 만합니다. 2024년 11월 5일부터 필터링은 두 가지 특성이 동시에 일치할 때만 작동합니다: cloudflare-ech.com의 SNI와 ECH 확장의 존재. 각각 단독으로는 차단을 유발하지 않으며 — ECH는 다른 위장 도메인(예: 테스트용 defo.ie 또는 tls-ech.dev)에 대해서는 통과합니다. 이는 연결을 끊는 것이 아니라 조용히 패킷을 버리는 방식으로 구현됩니다: 페이지가 멈추고 타임아웃으로 떨어집니다. TCP 기반 HTTP/2와 QUIC/HTTP-3 모두 영향을 받습니다. 당시 로스콤나드조르는 TLS ECH의 사용이 러시아 법률을 위반한다고 명시하고, 사이트 소유자에게 Cloudflare CDN에서 벗어나라고 권장했습니다 — 수천 개의 합법적인 리소스가 한 번에 필터에 걸렸습니다.

Firefox는 이러한 상황에서 약 1분 후에 ECH 없이 다시 시도합니다 — 즉, 최종적으로 열린 SNI를 반환하며, 이는 보안상의 이유로 사양에서 권장되지 않습니다. "사이트가 정확히 1분 동안 로드되고, 그 후 열립니다"라는 현상을 관찰한다면 — 거의 확실히 그것입니다.

언제 ECH가 충분하지 않으며 무엇을 대신 설치할 것인가

작업을 정직하게 나눠보겠습니다.

가정용 인터넷에서 제공자로부터의 프라이버시. ECH + DoH는 좋은 무료 개선책입니다. 잘 작동합니다, 차단되지 않는 곳에서.
필터 우회. ECH는 이를 위해 설계되지 않았으며, 실제로 그것이 필터에 방해가 되기 시작하자, 이를 식별하고 완전히 차단하는 방법을 배웠습니다. 접근 도구로서 이를 신뢰할 수 없습니다.
파싱, 멀티 계정, 자동화. ECH는 아무것도 제공하지 않습니다: 대상 사이트는 귀하의 IP, JA4 및 요청 기록을 봅니다. 중요한 것은 IP 출처와 지문 품질입니다.

모든 경우에서 ECH가 작동하지 않는 경우, 더 거칠지만 신뢰할 수 있는 레이어가 작동합니다: TLS 핸드셰이크를 관찰 가능한 네트워크 밖으로 이동시키는 것. 트래픽이 프록시를 통해 전송될 때, 귀하의 채널에서 관찰자는 프록시 노드와의 연결만 볼 수 있으며 — 대상 사이트의 SNI는 전혀 없습니다, 도메인이 ECH를 지원하든 아니든 관계없이. 일상적인 접근과 IP 평판에 민감한 서비스 작업을 위해서는 주거용 프록시가 적합하며, 모바일 애플리케이션과 연결 유형에 특히 까다로운 플랫폼의 경우에는 모바일 프록시가 적합합니다.

그리고 DNS를 잊지 마십시오: 브라우저의 프록시는 이름이 그를 통해 확인된다는 보장을 하지 않습니다. DNS 누출은 귀하가 숨기려고 했던 것을 정확히 드러냅니다 — 이를 확인하는 방법은 DNS 누출 검사를 위한 프록시 확인에 대한 별도의 지침에서 다루었습니다. 만약 질문이 채널의 깊은 트래픽 분석과 관련이 있다면, ECH가 아니라 전송 자체를 살펴봐야 합니다.

짧은 체크리스트

crypto.cloudflare.com/cdn-cgi/trace를 열고 sni= 줄을 확인합니다.
plaintext인 경우 — 브라우저에서 DoH를 활성화하고 다시 확인합니다.
도움이 되지 않았다면 — 도메인에 키가 있는지 확인합니다: dig +short TYPE65 도메인 @1.1.1.1, FE0D를 찾습니다.
키가 있지만 ECH가 적용되지 않는 경우 — 공개 리졸버와 시스템 리졸버의 응답을 비교합니다: 아마도 매개변수가 도중에 잘려나갑니다.
연결이 1분 동안 멈추고 열리면 — ECH가 네트워크 수준에서 차단되고 있습니다; ECH는 도움이 되지 않으며, 다른 전송이 필요합니다.

결론

ECH는 TLS의 프라이버시에서 조심스럽게 닫힌 마지막 구멍이지, 접근 수단이나 자동화 도구가 아닙니다. 이는 암호화된 DNS에 의존하며, 중간에 아무런 오류 없이 비활성화되고, 방해가 되기 시작하는 곳에서는 완전히 차단됩니다. 이를 확인할 가치가 있습니다 — 위의 두 명령은 1분 정도 걸립니다. 그러나 이를 차단 우회 도구나 안티봇 시스템으로부터의 보호 수단으로 삼는 것은 무의미합니다: 이러한 작업은 서버가 다른 쪽에서 어떤 IP와 어떤 TLS 지문을 보는지에 따라 해결됩니다.