HTTPS 통신도 추적 가능? SNI가 알려주는 비밀

“HTTPS면 안전하다”는 건 절반만 맞는 말입니다. 접속 도메인(SNI)은 여전히 노출되어, 누가 어떤 사이트에 접속했는지 추적이 가능합니다. 이번 글에서는 그 이유와, 이를 완전히 숨길 수 있는 최신 기술 ECH를 쉽게 설명합니다.

 

 

목차
   ­ㄴ 들어가며 — HTTPS는 정말 완벽할까?
   ­ㄴ HTTPS의 기본 구조와 암호화 원리
   ­ㄴ SNI(Server Name Indication)란 무엇인가
   ­ㄴ 실제 HTTPS 핸드셰이크에서 SNI가 노출되는 기술적 이유
   ­ㄴ HTTPS 통신에서도 노출되는 정보들
   ­ㄴ 왜 이게 문제일까 — 추적 가능성
   ­ㄴ 해결책: ECH(Encrypted Client Hello)의 등장
   ­ㄴ 마무리 — 진짜 ‘완전한 암호화’를 향하여

□  들어가며 — HTTPS는 정말 완벽할까?   

주소창 옆에 자물쇠 아이콘이 보이면 “안전하다”고 느끼죠. HTTPS(암호화 통신)는 데이터를 암호화해 외부에서 내용을 볼 수 없게 만듭니다. 하지만 의외로, 누가 어떤 사이트에 접속했는지 정도는 여전히 노출될 수 있습니다.
이 숨은 이유의 중심에는 SNI(Server Name Indication) 라는 기술이 있습니다.

□  HTTPS의 기본 구조와 암호화 원리   

HTTPS는 TLS(Transport Layer Security) 프로토콜 위에서 작동하며, 클라이언트(브라우저)와 서버가 “암호화 방식을 협상”하고 “세션 키”를 교환한 뒤 모든 데이터를 암호화해 통신합니다.

하지만 암호화가 시작되기 전, 서버는 어떤 인증서를 제시해야 하는지 알아야 합니다.
예를 들어 한 IP에서 여러 도메인을 운영하는 경우(abc.com, xyz.com 등), 서버는 클라이언트가 접속하려는 도메인 이름(hostname) 을 알아야 올바른 인증서를 제공합니다. 이 정보를 주고받는 역할이 바로 SNI 확장 필드입니다.

□  SNI(Server Name Indication)란 무엇인가   

SNI는 하나의 IP에 여러 웹사이트를 운영할 때, 클라이언트가 “내가 접속하려는 사이트는 ○○○입니다”라고 알려주는 기능입니다.
이 덕분에 서버는 그 도메인에 맞는 SSL 인증서를 제시할 수 있습니다. 하지만 문제는, 이 과정이 암호화되기 전에 진행된다는 것입니다. 즉, TLS 세션이 시작되기 전 전송되는 Client Hello 패킷에 SNI 정보가 포함되어 있고, 이 패킷은 암호화되지 않은 평문 상태로 네트워크를 지나갑니다.

□  실제 HTTPS 핸드셰이크에서 SNI가 노출되는 기술적 이유   

① 실제 접속

브라우저에서 https://www.naver.com 에 접속합니다.
Wireshark로 네트워크 트래픽을 캡처하면 새로운 Client Hello 패킷이 잡힙니다. 이 단계는 TLS 암호화가 시작되기 전, 클라이언트가 서버로 보낸 최초 요청입니다.

② SNI 확인 방법

Client Hello 패킷을 선택한 뒤 하단 상세 보기에서 아래 항목을 찾습니다.

Transport Layer Security → Extension: server_name

 

이를 펼치면 다음처럼 표시됩니다 

Extension: server_name (len=25)
    Server Name Indication extension
        Server Name: www.naver.com

 

Extension: server_name (len=25) Server Name Indication extension Server Name: www.naver.com  여기서 www.naver.com 부분이 평문으로 노출된 SNI 정보입니다.
즉, HTTPS를 사용해도 “누가 어떤 사이트에 접속했는가”는 네트워크에서 볼 수 있습니다.

③ 암호화 이후 단계

서버가 인증서를 보내고 키 교환이 완료되면, TLS 세션이 성립되어 암호화된 구간이 시작됩니다. 이후 모든 패킷은 아래처럼 보입니다:

Encrypted Application Data

Encrypted Application Data

즉, URL 경로, 쿠키, 요청 본문 등 실제 데이터는 완전히 암호화되어 볼 수 없습니다.

④ ECH(Encrypted Client Hello) 적용 시 최신 브라우저와 서버가 ECH(Encrypted Client Hello) 를 지원한다면, 위의 Server Name 필드가 더 이상 평문으로 표시되지 않습니다.

Wireshark에서는 다음처럼 나타납니다.

Encrypted Client Hello

 

Encrypted Client Hello  이 경우 감청자나 방화벽은 접속 도메인조차 알 수 없습니다.

ECH는 HTTPS의 완전한 프라이버시 보호를 실현하기 위한 차세대 기술입니다.

□  HTTPS 통신에서도 노출되는 정보들   

HTTPS는 콘텐츠를 암호화하지만, 여전히 다음 정보들은 네트워크 상에 노출됩니다.

• 접속한 서버 IP 주소
• 사용한 포트 번호 (기본 443)
• SNI 필드의 도메인명(hostname)
• TLS 버전, 암호화 알고리즘 정보

즉, ‘무엇을 보냈는가’는 보호되지만, ‘어디로 보냈는가’는 노출된다고 볼 수 있습니다.

□  왜 이게 문제일까 — 추적 가능성   

ISP, 공공 와이파이, 기업 방화벽 등은 SNI 정보를 이용해 특정 사이트 접속을 감시하거나 차단할 수 있습니다.

예를 들어,

• 회사 방화벽이 youtube.com 이 포함된 SNI를 탐지해 접속을 차단
• 정부나 기관이 특정 뉴스 사이트 방문을 감시 이런 식의 도메인 기반 필터링이 가능합니다.
  

□  해결책: ECH(Encrypted Client Hello)의 등장   

이 한계를 보완하기 위해 개발된 것이 ECH입니다.
기존의 ESNI(Encrypted SNI) 를 확장한 개념으로, SNI뿐 아니라 Client Hello 전체를 암호화합니다.

• 클라이언트와 서버 모두 ECH를 지원해야 동작
• 현재 Cloudflare, Firefox, Chrome 일부 버전에서 사용 가능
• 적용 시 접속 도메인 정보가 완전히 숨겨짐

즉, ECH는 HTTPS의 마지막 빈틈을 메우는 기술입니다.

□  마무리 — 진짜 ‘완전한 암호화’를 향하여   

HTTPS는 현대 인터넷 보안의 기본이지만, 그 안에도 설계상 남은 작은 틈이 있습니다.
SNI는 인증서 교환을 위해 반드시 필요했지만, 동시에 사용자 접속 정보가 평문으로 노출되는 구조적 약점이기도 합니다.

이제 ECH가 보편화된다면, “어디로, 무엇을, 어떻게” 모두 암호화된 진정한 종단 간 보안 통신이 실현될 것입니다.

감사합니다.