SNI

TLS 핸드셰이크는 클라이언트와 서버가 보안 연결을 설정하기 위해 수행하는 일련의 협상 과정이다. SNI는 이 핸드셰이크의 초기 단계인 ClientHello 메시지에 포함되어 전송된다. 클라이언트는 아직 암호화되지 않은 평문 상태로 접속하려는 서버의 도메인 이름을 이 확장 필드에 명시한다.

서버는 ClientHello 메시지를 수신하면 내부에 포함된 SNI 확장을 확인한다. 이를 통해 단일 IP 주소와 단일 포트를 공유하는 여러 개의 서로 다른 SSL/TLS 인증서 중에서 어떤 인증서를 사용하여 핸드셰이크를 진행해야 하는지 식별한다. 올바른 인증서를 선택한 서버는 해당 인증서를 ServerHello 메시지에 담아 클라이언트에게 응답하며, 이후의 핸드셰이크는 선택된 인증서를 기반으로 계속된다.

아래 표는 SNI가 포함된 기본적인 TLS 핸드셰이크 흐름을 요약한다.

만약 클라이언트가 SNI 확장을 보내지 않거나, 서버가 요청된 SNI 호스트명에 대한 서비스를 구성하지 않은 경우, 서버는 일반적으로 기본으로 설정된 인증서를 보내거나 핸드셰이크 실패 오류를 발생시킬 수 있다. 이 메커니즘은 HTTP/2나 HTTP/3와 같은 최신 프로토콜에서도 동일하게 적용된다.

클라이언트가 TLS 암호화 연결을 시작할 때, 서버는 클라이언트가 어떤 도메인 이름에 접속하려는지 알지 못합니다. 이는 하나의 IP 주소와 포트가 여러 개의 서로 다른 웹사이트(예: example.com과 example.net)를 호스팅하는 가상 호스팅 환경에서 문제가 됩니다. 서버는 클라이언트가 요청한 정확한 도메인에 맞는 인증서를 제공해야 하기 때문입니다.

SNI는 이 문제를 해결하기 위해 TLS 핸드셰이크의 초기 단계인 ClientHello 메시지에 접속하려는 서버의 도메인 이름을 평문으로 포함시킵니다. 구체적인 통신 흐름은 다음과 같습니다.

1. 클라이언트(예: 웹 브라우저)는 서버의 IP 주소로 연결을 시도합니다.

2. ClientHello 메시지를 생성할 때, extension 필드에 server_name 항목을 추가하고 여기에 접속하려는 호스트명(예: www.example.com)을 기록합니다.

3. 이 메시지를 서버로 보냅니다.

4. 서버는 ClientHello 메시지를 수신하고 server_name 확장 필드를 확인하여 클라이언트가 요청한 도메인 이름을 알아냅니다.

5. 서버는 확인된 도메인 이름에 해당하는 SSL/TLS 인증서를 선택하여 ServerHello 메시지와 함께 클라이언트에게 응답합니다.

6. 이후 핸드셰이크는 일반적인 절차대로 진행되어 암호화된 연결이 수립됩니다.

아래 표는 SNI를 사용한 일반적인 통신 단계를 요약한 것입니다.

이 과정 덕분에 서버는 연결 초기에 올바른 인증서를 제공할 수 있으며, 클라이언트는 정상적으로 암호화된 세션을 시작할 수 있습니다. 그러나 SNI 정보가 암호화되지 않은 평문으로 전송되기 때문에, 중간에서 관찰하는 제3자는 사용자가 접속하려는 웹사이트의 도메인 이름을 알 수 있다는 보안상의 문제가 제기되었습니다. 이 문제를 해결하기 위해 ESNI나 ECH 같은 SNI 암호화 확장 표준이 개발되고 있습니다.

가상 호스팅은 단일 서버와 하나의 IP 주소를 사용하여 여러 개의 독립적인 웹사이트나 도메인을 호스팅하는 기술이다. SNI는 특히 HTTPS 연결을 사용하는 가상 호스팅 환경에서 필수적인 역할을 수행한다. SSL/TLS 암호화가 적용되기 전에는, HTTP 프로토콜에서 클라이언트가 보내는 Host 헤더를 통해 서버가 요청된 사이트를 구분할 수 있었다. 그러나 TLS 핸드셰이크는 암호화 협상이 먼저 이루어지기 때문에, 서버는 클라이언트가 어떤 사이트에 접속하려는지 알기 전에 올바른 인증서를 제시해야 하는 문제에 직면했다.

이 문제를 해결하기 위해 SNI가 도입되었다. 클라이언트는 TLS 핸드셰이크의 초기 단계인 ClientHello 메시지에 접속하려는 서버의 도메인 이름을 평문으로 포함시킨다. 이를 수신한 웹 서버는 SNI 확장 필드에 명시된 도메인 이름을 확인하고, 해당 도메인에 맞는 SSL 인증서를 선택하여 핸드셰이크를 진행한다. 이 메커니즘 덕분에 서버 관리자는 다음과 같은 이점을 얻는다.

* 자원 효율성 향상: 여러 웹사이트를 위한 별도의 IP 주소와 물리적 서버를 구축할 필요가 없어져, 하드웨어 및 IPv4 주소 자원을 절약할 수 있다.

* 관리 편의성 증대: 하나의 서버 인스턴스에서 여러 도메인의 설정과 인증서를 통합 관리할 수

SNI는 콘텐츠 전송 네트워크 및 로드 밸런서가 효율적으로 작동하는 데 핵심적인 역할을 한다. 특히 하나의 IP 주소 뒤에 여러 개의 서로 다른 웹사이트나 서비스가 호스팅되는 환경에서, 들어오는 TLS 암호화 연결 요청을 올바른 백엔드 서버로 라우팅하기 위해 필요하다. SNI 확장이 없으면, 로드 밀런서나 CDN 에지 서버는 클라이언트가 암호화 핸드셰이크를 시작하기 전에 어느 사이트에 접속하려는지 알 수 없다.

CDN 제공업체는 전 세계에 분산된 수많은 에지 서버를 운영하며, 이 서버들은 종종 하나의 IP 주소를 공유하여 수천 개의 고객 도메인을 처리한다. 클라이언트가 연결을 시도하면, TLS 핸드셰이크의 첫 번째 메시지인 ClientHello에 포함된 SNI 필드를 통해 목표 도메인 이름을 확인한다. 이를 기반으로 CDN 시스템은 해당 도메인에 맞는 SSL/TLS 인증서를 선택하고, 캐시 정책 및 원본 서버 라우팅 규칙을 적용한다. 이 과정은 사용자에게 투명하게 이루어지며, 지리적으로 가까운 에지 서버에서 최적화된 콘텐츠를 빠르게 제공할 수 있게 한다.

로드 밸런서에서의 활용도 유사하다. 하나의 로드 밸런서 VIP 뒤에 여러 웹 서버 풀이 존재할 때, SNI 정보는 트래픽을 적절한 백엔드 풀로 전달하는 결정적 기준이 된다. 예를 들어, app1.example.com과 app2.example.com이 동일한 로드 밸런서를 통해 서비스된다면, 로드 밸런서는 SNI 값을 확인하여 각 도메인에 매핑된 서버 그룹으로 연결을 포워딩한다. 이는 7계층 로드 밸런싱의 기초를 이루며, 호스트 기반 라우팅을 가능하게 한다.

이러한 연동은 현대적인 클라우드 네이티브 아키텍처와 마이크로서비스 환경에서 필수적이다. 다만, SNI 정보가 암호화되지 않은 채 전송된다는 점은 ESNI나 ECH 같은 암호화 기술 발전의 동기가 되었다.

TLS 핸드셰이크의 초기 단계에서 전송되는 SNI 확장은 평문으로 전송됩니다. 이는 클라이언트가 접속하려는 서버의 도메인 이름을 서버가 알 수 있도록 하기 위한 필수 과정이지만, 동시에 네트워크 관찰자가 사용자가 방문하는 사이트의 도메인을 쉽게 식별할 수 있게 만드는 정보 유출 문제를 야기합니다. 이 문제를 해결하기 위해 SNI 정보를 암호화하는 표준이 개발되었으며, 그 진화 과정은 ESNI에서 ECH로 이어집니다.

초기 대응책인 ESNI는 TLS 1.3을 기반으로 하여, 클라이언트가 공개 DNS 레코드(TXT 레코드)를 통해 사전에 획득한 서버의 공개키로 SNI 값을 암호화하는 방식을 사용했습니다. 이로 인해 핸드셰이크 과정에서 외부 관찰자는 암호화된 SNI 값만을 볼 수 있게 되었습니다. 그러나 ESNI는 몇 가지 실용적인 한계가 있었습니다. 가장 큰 문제는 암호화된 SNI를 사용하려면 반드시 TLS 1.3과 공개 DNS 조회가 선행되어야 한다는 점이었으며, 프록시나 중간 네트워크 장비가 정상적인 핸드셰이크를 관찰해야 하는 경우 등에서 호환성 문제가 발생할 수 있었습니다.

이러한 한계를 극복하고 더 강력한 프라이버시 보호를 제공하기 위해 개발된 최종 표준이 ECH입니다. ECH는 핸드셰이크 과정 자체를 재설계하여 SNI 암호화를 더 깊이 통합합니다. ECH에서는 클라이언트가 두 개의 연결 시도를 하나의 암호화된 패키지로 합칩니다. 하나는 공개적으로 알려진 '외관' 도메인(예: CDN 제공자의 도메인)으로의 연결 시도이고, 다른 하나는 실제 목적지인 '내부' 도메인에 대한 암호화된 연결 시도입니다. 서버는 이 패키지를 해독하여 실제 의도된 연결을 성립시킵니다. 이 방식은 네트워크 관찰자에게는 사용자가 단지 '외관' 도메인에 연결하는 것처럼만 보이게 만들어, 실제 방문 사이트를 더 효과적으로 숨깁니다. ECH는 TLS 표준의 일부로 통합되어 보다 광범위한 지원과 적용이 기대됩니다.

SNI 확장은 암호화되지 않은 평문으로 전송되기 때문에, 제3자가 네트워크 트래픽을 관찰(감청)할 경우 사용자가 접속하려는 웹사이트의 도메인 이름을 식별할 수 있다. 이는 TLS 핸드셰이크의 주요 목적인 통신 내용의 기밀성과는 별개로, 메타데이터가 노출되는 문제를 일으킨다.

감시 가능성은 몇 가지 측면에서 문제가 된다. 첫째, 정부나 인터넷 서비스 제공업체(ISP)가 특정 도메인에 대한 접속을 차단(예: 국가별 인터넷 검열)하거나 모니터링하는 데 SNI 정보를 활용할 수 있다. 둘째, 네트워크 관리자가 특정 서비스(예: 스트리밍, 소셜 미디어)의 트래픽을 식별하여 대역폭을 제한하거나 차별할 수 있는 가능성이 있다. 셋째, 공격자가 사용자의 웹 서핑 패턴을 추적하여 개인적인 관심사나 행동 프로필을 구성하는 데 이 정보를 이용할 수 있다.

이러한 정보 유출 문제를 완화하기 위해 암호화된 SNI(ESNI) 및 그 후속인 TLS 암호화 클라이언트 헬로(ECH) 표준이 개발되었다. 이 기술들은 SNI 필드 자체를 암호화하여, 오직 목표 서버만이 클라이언트가 요청한 호스트명을 알 수 있도록 한다. 그러나 이들의 광범위한 채택에는 DNS over HTTPS(DoH) 같은 지원 인프라의 배포와 클라이언트 및 서버 양측의 구현이 필요하다.

SNI를 지원하는 웹 서버에서는 하나의 IP 주소와 포트로 여러 개의 SSL/TLS 인증서를 호스팅할 수 있다. 이를 위해서는 서버 소프트웨어의 설정 파일에서 가상 호스트(Virtual Host) 블록 내에 각 도메인에 대한 인증서 경로를 명시해야 한다.

아래는 주요 웹 서버에서의 기본적인 설정 방법이다.

Apache의 경우, mod_ssl 모듈이 로드되어 있어야 하며, 설정은 일반적으로 다음과 유사하다.

```

<VirtualHost *:443>

ServerName www.example.com

SSLEngine on

SSLCertificateFile /path/to/www.example.com.crt

SSLCertificateKeyFile /path/to/www.example.com.key

</VirtualHost>

<VirtualHost *:443>

ServerName www.another-example.com

SSLEngine on

SSLCertificateFile /path/to/www.another-example.com.crt

SSLCertificateKeyFile /path/to/www.another-example.com.key

</VirtualHost>

```

Nginx에서는 ssl 지시어와 함께 server_name으로 구분한다.

```

server {

listen 443 ssl;

server_name www.example.com;

ssl_certificate /path/to/www.example.com.crt;

ssl_certificate_key /path/to/www.example.com.key;

...

}

server {

listen 443 ssl;

server_name www.another-example.com;

ssl_certificate /path/to/www.another-example.com.crt;

ssl_certificate_key /path/to/www.another-example.com.key;

...

}

```

모든 설정을 마친 후에는 웹 서버를 재시작하여 변경 사항을 적용해야 한다. 서버는 클라이언트가 TLS 핸드셰이크 초기에 보내는 SNI 확장 필드의 호스트 이름을 확인하고, 일치하는 가상 호스트 블록의 인증서를 사용하여 암호화 연결을 완성한다. 이 설정을 통해 물리적 서버 자원을 효율적으로 활용할 수 있다.

대부분의 현대 웹 브라우저와 주요 운영체제는 SNI 확장을 지원한다. 초기 지원은 TLS 1.0과 함께 도입되었으며, 시간이 지남에 따라 광범위하게 채택되었다.

주요 데스크톱 및 모바일 브라우저의 지원 현황은 다음과 같다.

운영체제 측면에서는, 리눅스, macOS, Windows의 최신 버전들이 내장된 TLS 라이브러리(OpenSSL, Secure Transport, Schannel 등)를 통해 SNI를 지원한다. 안드로이드의 경우 2.3 진저브레드 이후의 버전에서 대부분의 브라우저와 앱이 지원한다. 그러나 매우 오래된 운영체제나 임베디드 시스템, 또는 사용자 정의 펌웨어를 사용하는 일부 장치에서는 SNI 지원이 누락되어 가상 호스팅 환경의 최신 SSL/TLS 사이트에 접근하지 못하는 문제가 발생할 수 있다.