SNI가 등장한 배경

SNI (Server Name Indication)가 등장한 배경

과거 HTTPS  한계                                                                                       결과

 

TLS 핸드셰이크가 HTTP Host 헤더보다 먼저 진행 → 서버는 “어떤 도메인”으로 접속했는지 알 수 없었음	한 IP(혹은 한 포트)에서 하나의 인증서만 제시 가능
여러 독립 도메인을 같은 서버에 호스팅하려면	① 도메인마다 전용 IP를 할당하거나 ② SAN(Subject Alt Name) 인증서로 여러 이름을 한 증서에 묶어야 했음
문제점	• IPv4 주소 고갈 & 비용 증가 • SAN 증서 변경·재발급 부담 • “HTTPS는 돈‧운영 부담이 큰 특수 옵션”이라는 인식

 

결국 “**가상 호스팅(virtual hosting)**을 HTTPS에서도 자유롭게 쓰려면, TLS 핸드셰이크 단계에서 클라이언트가 요청 도메인을 먼저 알려줘야 한다”는 요구가 생겼습니다.

SNI의 탄생

연혁                 내용

 

2003 년 6 월	IETF RFC 3546 TLS Extensions에 SNI 초안 채택 (server_name 확장) rfc-editor.org
2011 년 6 월	수정·확장판 RFC 6066 발행 – 현재 표준
2006 ~ 2013	OpenSSL 0.9.8f, Apache 2.2.12, Nginx 0.6+, IIS 8, 주요 브라우저(NSS 3.11, IE 7/Vista, iOS 4, Android 3…)가 차례로 지원

 

동작 방식 (고수준)

1. ClientHello
   클라이언트가 TLS 연결을 시작하면서 extensions.server_name = example.com 을 포함
2. 서버
   첫 패킷에서 도메인을 확인 → 매칭되는 가상호스트(인증서·키·설정)를 선택
3. 나머지 핸드셰이크 진행
   올바른 인증서를 제시 → 동일 IP에서 여러 도메인 + 각각 다른 인증서 운용 가능

도입 효과

효과                                설명

 

IP 주소 절감	한 개(또는 소수)의 IP로 수십·수백 도메인을 HTTPS로 서비스
운영 단순화	기존 HTTP 가상호스팅 모델을 TLS에도 일관 적용
HTTPS 대중화	“Let’s Encrypt + SNI” 조합으로 무료·자동 인증서 갱신이 현실화 (2015~)

 

여전히 남은 과제

한계                                                                                           대응 기술

 

SNI 확장 자체는 암호화되지 않음 → 패시브 감청자가 목적 도메인을 식별 가능	ECH (Encrypted Client Hello): SNI를 포함한 ClientHello 확장 암호화 (TLS 1.3+)
레거시 클라이언트 미지원	매우 오래된 XP SP2/IE 6, 안드로이드 2.x 등에서 접속 불가 → 현실적 영향 미미

 

요약

SNI는 “여러 HTTPS 사이트를 하나의 IP에서 서비스하게 만들기 위해” TLS 핸드셰이크에 도메인 이름을 포함하도록 확장한 기술입니다. 이로써 IP 고갈·운영 비용 문제를 해결하며 HTTPS 보급의 결정적 전환점이 되었습니다.