인터넷 패러다임이 HTTP에서 HTTPS로 전환되면서, 네트워크상의 데이터는 강력하게 보호받기 시작했습니다. 하지만 보안의 강화는 역설적으로 '네트워크 관리와 통제'의 난이도를 높였습니다. 악성코드 유포 사이트, 기업 기밀 유출 경로, 불법 콘텐츠 허브 등이 HTTPS의 암호화 장벽 뒤로 숨어버렸기 때문입니다.
이러한 상황에서 네트워크 관리자와 통신사(ISP)가 암호화된 트래픽을 효율적으로 선별하고 차단하기 위해 도입한 핵심 기술이 바로 SNI(Server Name Indication) 필드 차단입니다. 본 장에서는 SNI 차단의 기반이 되는 웹 프로토콜의 진화 과정을 살펴보고, 차단 기술의 상세 메커니즘과 우회 기술 간의 기술적 공방을 심층적으로 다뤄보고자 합니다.
1. 사전 기반 지식: 웹 프로토콜의 진화와 가상 호스팅
SNI 차단을 완벽히 이해하기 위해서는 먼저 HTTP/1.1의 가상 호스팅(Virtual Hosting)과 HTTPS의 TLS 핸드셰이크 메커니즘을 명확히 정리해야 합니다.
1.1 IP 주소의 한계와 가상 호스팅 (HTTP Request Header: Host)
과거 인터넷 초기에는 하나의 물리적 서버(하나의 IP 주소)가 하나의 도메인(웹사이트)만 서비스하는 것이 일반적이었습니다. 그러나 웹사이트의 수가 폭발적으로 증가하면서 IPv4 주소 고갈 문제와 서버 자원 낭비 문제가 대두되었습니다.
이를 해결하기 위해 탄생한 개념이 가상 호스팅(Virtual Hosting)입니다. 하나의 IP 주소를 가진 서버가 여러 개의 도메인(예: company.com, blog.net, shop.org)을 동시에 서비스하는 기술입니다.
HTTP/1.1 표준에서는 이를 구현하기 위해 Host 헤더를 필수 항목으로 지정했습니다.
- 사용자가 브라우저에 주소를 입력하면, 브라우저는 DNS를 통해 IP를 얻은 뒤 서버와 TCP 연결을 맺습니다.
- 그 후 보낼 HTTP 요청 메시지 헤더에 Host: company.com을 명시합니다.
- 웹 서버(Apache, Nginx 등)는 이 Host 헤더를 읽고, 동일한 IP 내에서 어떤 웹사이트의 데이터를 반환할지 결정합니다.

1.2 HTTPS의 등장과 가상 호스팅의 충돌
보안성 강화를 위해 HTTP에 암호화 프로토콜인 TLS(Transport Layer Security)를 얹은 HTTPS가 표준화되면서 중대한 기술적 모순이 발생했습니다.
HTTPS 통신은 TCP 연결이 수립된 직후, HTTP 요청을 보내기 전에 안전한 암호화 채널을 구축하는 TLS 핸드셰이크(Handshake) 단계부터 시작합니다.
- 클라이언트가 서버에 "암호화 통신을 시작하자"며 Client Hello 메시지를 보냅니다.
- 서버는 자신의 신원을 증명할 SSL/TLS 인증서(Certificate)를 클라이언트에 보냅니다.
- 클라이언트는 인증서를 검증한 뒤 암호화 키를 생성하고, 이후부터 모든 HTTP 데이터를 암호화합니다.
여기서 문제가 발생합니다. 서버가 인증서를 보내는 시점(2단계)은 아직 HTTP 요청이 발생하기 전이므로, 서버는 사용자가 어떤 도메인(Host 헤더) 접속을 원하는지 전혀 모르는 상태입니다. 하나의 IP에 여러 도메인이 얹혀 있는 가상 호스팅 서버라면, "수많은 사이트 중 어떤 사이트의 인증서를 꺼내서 보내주어야 하는가?"에 대한 딜레마에 빠지게 됩니다. 잘못된 인증서를 보내면 브라우저에는 '보안 경고(인증서 오류)'가 발생하게 됩니다.
2. SNI(Server Name Indication) 프로토콜의 탄생
이 문제를 해결하기 위해 2003년 IETF(인터넷 표준 기구)는 TLS 1.0의 확장 규격(RFC 3546, 이후 RFC 6066으로 개정)으로 SNI(서버 이름 표시) 기술을 제안했습니다.
2.1 SNI의 기본 메커니즘
원리는 간단합니다. 서버가 인증서를 고를 수 있도록, 클라이언트가 TLS 핸드셰이크의 첫 번째 패킷인 Client Hello의 확장(Extension) 필드에 접속하고자 하는 도메인 이름을 미리 적어서 보내는 것입니다.
- 동작 방식: 사용자가 https://example.com에 접속하려 할 때, Client Hello 패킷 내부의 Server Name 필드에 명시적으로 example.com이라는 문자열을 삽입하여 전송합니다.
- 결과: 서버는 이 SNI 필드를 먼저 읽고, 해당 도메인에 정확히 매칭되는 SSL/TLS 인증서를 선택하여 클라이언트에 응답할 수 있게 되었습니다. 이로써 HTTPS 환경에서도 하나의 IP 주소로 수백 개의 암호화된 가상 호스팅 사이트를 안정적으로 운영할 수 있게 되었습니다.
3. SNI 필드 차단의 메커니즘과 동작 원리
SNI는 가상 호스팅 문제를 훌륭히 해결했지만, 보안 측면에서 치명적인 아킬레스건을 남겼습니다. 바로 Client Hello 패킷이 송신되는 시점은 암호화 키를 교환하기 전이기 때문에, SNI 필드에 적힌 도메인 정보가 평문(Plaintext)으로 전송된다는 점입니다.
네트워크 관리자나 ISP(통신사)는 이 약점을 이용해 HTTPS 트래픽을 정교하게 통제하는 SNI 필드 차단 기술을 개발했습니다.

3.1 차단 프로세스 (5단계)
SNI 필드 차단은 일반적인 방화벽보다 훨씬 정교한 패킷 분석 기술인 DPI(Deep Packet Inspection, 심층 패킷 분석) 장비를 기반으로 동작합니다.
- TCP 3-Way Handshake 수립: 클라이언트와 서버 간의 기본적인 네트워크 연결(L4 Layer에서 진행)이 성립됩니다.
- TLS Client Hello 감시 (L7 Layer 분석): 클라이언트가 서버로 TLS 통신 시작 패킷을 보냅니다. 네트워크 중간에 위치한 DPI 장비는 이 패킷을 캡처하여 L7(Application Layer) 영역까지 뜯어봅니다.
- SNI 평문 문자열 추출: DPI 장비는 Client Hello 내 확장 필드에 노출된 Server Name(예: illegal-site.com) 문자열을 추출합니다.
- 블랙리스트(Blacklist) 매칭: 추출한 도메인을 정부(방송통신심의위원회 등)나 기업 보안 정책에 의해 지정된 '차단 대상 데이터베이스(DB)'와 실시간으로 대조합니다.
- 연결 강제 차단 (TCP RST 또는 리다이렉트): 만약 일치하는 도메인이 있다면, DPI 장비는 서버인 척 가장하여 클라이언트에게 TCP RST(Reset) 패킷을 보내 연결을 강제로 끊어버립니다.
- 또는 클라이언트에게 차단 안내 웹페이지(예: warning.or.kr)의 IP로 접속하라는 가짜 응답을 보내 브라우저 화면을 전환시킵니다.
3.2 타 차단 기술과의 비교 분석
네트워크 통제 기술의 발전 과정을 이해하면 SNI 차단의 위치를 더 명확히 알 수 있습니다.
- IP 주소 차단: 특정 서버의 IP 전체를 막는 방식입니다. 가상 호스팅 환경에서 이 방식을 쓰면, 유해 사이트 하나를 막으려다 같은 IP를 쓰는 수많은 정상 사이트까지 무고하게 차단되는 '과잉 차단(Collateral Damage)' 문제가 발생합니다.
- DNS 차단: 사용자가 도메인을 조회할 때 DNS 서버가 가짜 IP를 알려주는 방식입니다. 사용자가 구글(8.8.8.8)이나 클라우드플레어(1.1.1.1) 같은 해외 통설 DNS를 설정하거나, DNS 패킷 자체를 암호화하는 DoH/DoT 기술을 쓰면 쉽게 우회됩니다.
- SNI 필드 차단: IP가 같아도 도메인 단위로 정밀 타격이 가능하며, DNS를 우회하여 서버와 직접 IP 통신을 시도하더라도 핸드셰이크 과정에서 무조건 걸려들기 때문에 훨씬 강력합니다.
4. 관련 핵심 네트워크 프로토콜 및 기술 용어 정리
SNI 차단을 논할 때 실무 및 전공 시험에서 반드시 출제되는 핵심 기술적 키워드들입니다.
- DPI (Deep Packet Inspection, 심층 패킷 분석): 네트워크 패킷의 헤더(IP, Port)뿐만 아니라 데이터가 담긴 페이로드(Payload) 내부의 콘텐츠와 프로토콜 정보까지 분석하는 고성능 패킷 처리 기술입니다.
- TCP RST (Reset) 패킷: TCP 헤더의 플래그 중 하나로, 연결 상태에 이상이 있거나 강제로 세션을 종료해야 할 때 보내는 패킷입니다. SNI 차단 장비는 이 패킷을 양방향으로 쏘아 클라이언트와 서버가 서로 '상대방이 연결을 끊었다'고 믿게 만듭니다.
- TLS 1.3: 2018년에 제정된 최신 암호화 프로토콜 표준입니다. 핸드셰이크 과정을 기존 2-RTT에서 1-RTT로 단축하여 속도를 높였고, 기존 TLS 1.2에서 평문으로 노출되던 많은 필드들을 암호화 영역으로 격하했습니다. 그러나 이 TLS 1.3조차도 첫 번째 Client Hello 내의 SNI 필드는 평문으로 남겨두었습니다.
5. SNI 차단의 한계와 차세대 보안 기술: ESNI에서 ECH까지
창과 방패의 싸움처럼, 암호화 도메인 정보를 훔쳐보려는 차단 기술에 맞서 이를 완전히 숨기려는 웹 표준 기술이 계속해서 진화하고 있습니다.
5.1 ESNI (Encrypted SNI)
DPI 장비가 SNI를 읽지 못하도록 아예 SNI 필드를 암호화해서 보내자는 아이디어로 출발한 기술입니다.
- 원리: 웹 서버는 자신의 공개키 정보를 DNS 레코드(TXT 레코드)에 미리 등록해 둡니다. 클라이언트는 DNS를 통해 서버의 공개키를 먼저 받아온 뒤, 이 키로 SNI 필드를 암호화하여 Client Hello를 보냅니다.
- 한계: SNI 필드는 숨겼지만, Client Hello 메시지 내의 다른 필드(예: ALPN 프로토콜 목록, 키 교환 파라미터 등)는 여전히 평문으로 남았습니다. 정교한 DPI 장비는 이 주변 정보들의 '지문(Fingerprint)'을 분석하여 어떤 사이트로 가는지 유추해 내는 트래픽 분석(Traffic Analysis) 공격으로 ESNI를 무력화했습니다. 결국 ESNI는 표준화되지 못하고 사장되었습니다.
5.2 ECH (Encrypted Client Hello)
ESNI의 실패를 거울삼아 탄생한 최종 진화형 기술이 현재 인터넷 표준으로 자리 잡아가고 있는 ECH입니다.

- 원리: 일부 필드만 암호화하던 ESNI와 달리, ECH는 Client Hello 메시지 자체를 두 개로 쪼갭니다.
- Inner Client Hello (내부 메시지): 진짜 가고자 하는 도메인(SNI)을 포함한 모든 핵심 정보가 들어있으며, 서버의 공개키로 전체 암호화됩니다.
- Outer Client Hello (외부 메시지): DPI 장비가 읽을 수 있는 평문 메시지입니다. 하지만 여기에는 검열을 피하기 위해 클라우드플레어 같은 대형 CDN 업체의 대표 도메인 등 '가짜 혹은 공통 목적지 정보'를 적어 둡니다.
- 결과: 네트워크 중간에서 패킷을 훔쳐보는 검열 장비는 오직 외부 메시지(Outer)만 볼 수 있으므로, 사용자가 그 안의 진짜 목적지(Inner)로 가는지 전혀 알 수 없습니다.
6. 결론 및 생각해볼 점
SNI 필드 차단은 네트워크 자원의 효율적 통제와 유해 환경 차단이라는 '공익적/관리적 목적'과, 개인의 통신 자유 및 프라이버시 침해라는 '보안적/인권적 가치'가 정면으로 충돌하는 지점에 있습니다.
현재 직장인들이 사용하는 사내 보안 솔루션(DLP, 방화벽) 역시 사내 기밀 유출을 막기 위해 SNI 차단이나 더 나아가 SSL Inspection(인증서 프록시를 통한 복호화) 기술을 적극적으로 활용하고 있습니다. 향후 ECH 기술이 전면 도입되어 SNI 차단이 기술적으로 완전히 불가능해질 때, 기업과 국가는 새로운 네트워크 통제 거버넌스를 어떻게 구축해야 할지 고민해야 할 시점이라고 생각합니다.
'네트워크' 카테고리의 다른 글
| [네트워크]무선 매체 프로토콜의 진화 과정 (1) | 2026.06.05 |
|---|---|
| [네트워크]EDNS Client Subnet (ECS) (0) | 2026.05.31 |
| [네트워크]Wi-Fi 7의 핵심 기술 정리: 차세대 무선 통신 표준 (0) | 2026.04.15 |
| [네트워크]ECMP(Equal-Cost Multi-Path)의 원리와 부하 분산 알고리즘 (0) | 2026.04.06 |
| [네트워크]수리카타룰 (0) | 2026.04.01 |