상위 1000개 사이트 중 방문 호스트 이름을 숨기는 곳은 10곳뿐입니다 — 이를 세는 도구를 만들었습니다

AI 요약

HTTPS는 전송 내용을 암호화하지만, 사용자가 어느 사이트에 접속하는지까지 항상 숨겨주지는 않습니다. 방문 도메인의 호스트 이름은 TLS 연결을 시작할 때 교환하는 ClientHello에 들어갈 수 있으며, 네트워크 경로에 있는 관찰자는 이 값을 읽을 수 있습니다. 이 글은 이 문제를 직접 확인할 수 있도록 만든 도구와, 그 도구로 트래픽 상위 1000개 도메인을 조사한 결과를 설명합니다.

■ 공개 DNS만으로 ECH 지원 여부 확인

도구에 도메인을 입력하면 해당 도메인의 공개 DNS를 조회해 두 가지를 알려줍니다. 첫째는 사이트가 Encrypted ClientHello(ECH) 설정을 게시했는지 여부입니다. 둘째는 ECH가 활성화되어 있다면 실제 호스트 이름 대신 네트워크 관찰자에게 보일 커버 이름(cover name)이 무엇인지입니다. 이 과정에서는 대상 사이트와 TLS 핸드셰이크를 수행하지 않고, ECH 키도 필요로 하지 않습니다. 확인에 필요한 정보가 공개 DNS에 이미 있기 때문입니다.

ECH를 지원하는 사이트는 DNS의 HTTPS 레코드에 공개 키를 게시합니다. 이 레코드는 Application-Layer Protocol Negotiation(ALPN) 목록이나 IP 힌트 같은 정보도 전달하는 레코드입니다. 도구는 DNS over HTTPS(DoH)를 통해 이 레코드를 가져온 뒤, `ech=` 매개변수가 있는지 확인합니다. 값이 있으면 필요한 수준까지 디코딩해 ECH 버전, 키 교환 알고리즘, `public_name`을 읽습니다. 여기서 `public_name`이 실제로 방문한 호스트 이름을 대신해 전선상에 나타나는 커버 호스트 이름입니다.

도구의 도메인별 검사는 짧은 함수 하나로 구성되어 있으며, 조회 대상 사이트에는 아무것도 전송하지 않습니다. 입력한 도메인도 기록하지 않습니다. 공개 DNS 정보만 읽으면 되기 때문에 실행 비용이 낮고, 별도의 계정이나 비밀 키 없이 인프라의 ECH 설정을 점검할 수 있다는 점을 강조합니다.

■ 상위 1000개 도메인에서 ECH는 사실상 부재

작성자는 단일 도메인을 확인하는 데서 그치지 않고, 도메인 목록을 입력받는 커맨드라인 기능으로 트래픽 상위 1000개 도메인을 조사했습니다. 그 결과 ECH를 게시한 도메인은 10곳이라고 보고합니다. 나머지 중 992곳은 앞서 설명한 방식으로 호스트 이름을 그대로 노출했으며, 나머지는 DNS 해석에 실패했다고 설명합니다.

글에서 제시한 ECH 활성화 도메인은 `tinyurl.com`, `cedexis.net`, `sagepub.com`, `sxyprn.com`, `gizmodo.com`, `animeflv.net`, `remove.bg`, `arnebrachhold.de`, `yayoye-spiele.com`입니다. 이 도메인들은 모두 `cloudflare-ech.com`을 커버 이름으로 사용합니다. Google, Amazon, Microsoft, 은행 사이트는 목록에 포함되지 않았습니다. 작성자는 이를 개별 사이트들이 각자 프라이버시 기능을 선택한 결과라기보다, Cloudflare를 사용하는 일부 고객 영역에서 Cloudflare가 ECH를 활성화한 결과로 해석합니다. Cloudflare의 루트 도메인인 `cloudflare.com`도 ECH 레코드를 게시하지 않지만, `crypto.cloudflare.com` 테스트 호스트는 게시한다고 덧붙입니다.

■ ECH가 널리 활성화되지 않은 이유

작성자는 자신이 운영하는 축구 퀴즈 사이트 `extratime.world`도 확인했으며, 다른 992개 도메인과 마찬가지로 호스트 이름을 노출한다고 설명합니다. ECH는 기본값으로 켜져 있지 않고, DNS 제공업체와 콘텐츠 전송 네트워크(CDN)가 함께 지원해야 하며, 방문자의 DNS도 암호화되어 있어야 실제로 도움이 됩니다. 따라서 단순한 체크박스 하나가 아니라 서로 다른 네 주체의 설정이 맞아야 하는 기능이라고 설명합니다.

글은 “웹의 1%가 ECH를 지원한다”는 식의 표현을 그대로 일반화해서는 안 된다고 주의합니다. 이번 측정은 특정 트래픽 순위에서 뽑은 상위 1000개 목록을 하루 동안 조사했고, 하나의 DoH 제공업체를 통해 해석한 결과이기 때문입니다. 다른 순위 목록을 사용하거나 다음 달에 다시 조사하면 숫자가 달라질 수 있습니다. 또한 소규모 Cloudflare 호스팅 사이트까지 포함하면 비율이 더 높을 가능성이 있다고 설명합니다. 따라서 더 정확한 결론은 전체 웹의 비율이 아니라, 네트워크 관찰자가 특히 추적하고 싶어 할 만한 최상위 방문 사이트에서 ECH가 거의 보이지 않으며, 발견된 사례도 한 제공업체의 설정에 집중되어 있다는 것입니다.

■ 오픈소스 실행과 운영 과정에서 얻은 교훈

작성자는 스크린샷을 찍는 동안 독일 프랑크푸르트의 1 vCPU DigitalOcean 드롭릿에 도구를 배포했습니다. 이후 드롭릿을 삭제해 공개 인스턴스는 더 이상 제공하지 않으며, 비용이 계속 발생하지 않도록 했다고 설명합니다. 대신 도구 전체를 오픈소스로 공개했고, Docker로 직접 실행할 수 있습니다.

`git clone https://github.com/oceanforge/sni-leak-check` `cd sni-leak-check && docker compose up --build`

두 명령을 실행하면 `localhost:8000`에서 자신의 복사본을 사용할 수 있습니다. 인프라를 검사하는 도구인 만큼 다른 사람이 운영하는 서버에 도메인을 입력하기보다 직접 실행하는 편이 적절하며, 이 프로젝트는 작은 컨테이너 하나로 동작해 직접 운영하기 어렵지 않다고 설명합니다.

초기 테스트에서는 포트 8000에 이미 다른 프로젝트의 관리자 API가 실행 중이어서 새 애플리케이션 대신 전혀 다른 HTML이 반환되었습니다. 헬스 체크는 해당 포트에 정상적인 서비스가 있었기 때문에 통과했습니다. 작성자는 이 경험을 통해 녹색 상태나 HTTP 200 응답만으로는 자신이 테스트한다고 생각한 서비스가 실제로 응답했는지 증명할 수 없다고 말합니다. 사용하지 않는 포트로 옮기고, 상태 코드뿐 아니라 페이지 제목까지 직접 확인해 문제를 해결했으며 이후에는 페이지 제목도 검사한다고 설명합니다.

■ 후속 개발과 HTTPS의 두 가지 약속

저장소에는 원시 ECH 바이트를 각 필드와 함께 표시하기, 대량 검사 결과를 표로 보여주기, 공유 가능한 퍼머링크 만들기, 실제 ClientHello를 캡처해 추론이 아니라 관측으로 호스트 이름 노출을 보여주기 같은 첫 기여용 이슈가 등록되어 있습니다. 작은 단위의 이슈로 구성했으며 Hacktoberfest 참여자가 기여할 수 있도록 라벨도 붙였다고 안내합니다.

이 도구는 HTTPS가 두 가지 서로 다른 약속을 한다는 기존 논지를 실행 가능한 형태로 바꿉니다. HTTPS는 대화 내용의 프라이버시는 지켜주지만, 대화 상대 목록에 해당하는 방문 호스트 이름까지 자동으로 감추지는 않습니다. ECH 설정을 공개 DNS에서 직접 확인하면, 평소 사용하는 사이트 대부분이 어떤 상태인지 약 1초 안에 확인할 수 있다고 글은 설명합니다.

원문: dev.to / 번역·요약: Trawling