Server Name Indication

Server Name Indication (SNI) — это расширение протокола Transport Layer Security (TLS), которое позволяет клиенту (например, веб-браузеру) указывать имя хоста (доменное имя), к которому он пытается подключиться, на этапе рукопожатия TLS. Это решает проблему, когда на одном IP-адресе и одном порту (обычно 443) работает несколько веб-сайтов с разными SSL/TLS-сертификатами, и серверу необходимо заранее знать, какой именно сертификат предоставить клиенту.

История и предпосылки

До появления SNI, при использовании HTTPS, каждый IP-адрес мог обслуживать только один домен с отдельным SSL/TLS-сертификатом. Это было связано с тем, что процесс установления защищённого соединения (TLS-рукопожатие) происходит до того, как клиент отправляет HTTP-запрос, в котором обычно указывается имя хоста (заголовок Host). Сервер, не зная, какой сайт запрашивает клиент, мог предоставить только один сертификат, действительный для всех сайтов на этом IP.

С ростом числа веб-сайтов и необходимостью экономии IPv4-адресов, возникла потребность в технологии, позволяющей размещать множество сайтов с разными сертификатами на одном IP-адресе. SNI был предложен как расширение протокола TLS в 2003 году в документе RFC 3546, а затем уточнён в RFC 6066 (2011 год). Первоначальная поддержка SNI была реализована в браузерах и серверах в середине 2000-х годов.

Принцип работы

SNI работает на этапе TLS-рукопожатия, в частности, во время сообщения ClientHello, которое клиент отправляет серверу для инициирования соединения. В стандартном TLS-рукопожатии ClientHello содержит список поддерживаемых шифров, версий протокола и другие параметры. SNI добавляет в это сообщение поле server_name, в котором указывается доменное имя, запрашиваемое клиентом.

1. Клиент (браузер, приложение) при попытке открыть сайт example.com по HTTPS формирует ClientHello, в которое включает SNI-расширение с именем example.com.
2. Сервер (веб-сервер, балансировщик нагрузки) получает ClientHello и извлекает имя хоста из SNI.
3. На основе полученного имени сервер выбирает соответствующий SSL/TLS-сертификат из своей конфигурации.
4. Сервер отправляет клиенту сообщение ServerHello, содержащее выбранный сертификат.
5. Клиент проверяет, что сертификат действителен для домена example.com, и завершает рукопожатие.

Если сервер не поддерживает SNI или не находит соответствующего сертификата, он может либо выдать сертификат по умолчанию (например, для первого сайта в конфигурации), либо разорвать соединение.

Классификация и варианты реализации

SNI является стандартным расширением и поддерживается всеми современными веб-серверами, прокси-серверами и клиентами. Однако существуют различные подходы к его реализации и обработке.

По типу серверного ПО

• Apache HTTP Server: Поддержка SNI реализована через модуль mod_ssl. Для каждого виртуального хоста указывается свой сертификат.
• Nginx: Поддержка SNI встроена в модуль ngx_http_ssl_module. Сервер автоматически выбирает сертификат на основе имени хоста, указанного в server_name.
• Microsoft IIS: Поддержка SNI появилась в IIS 8 (Windows Server 2012). Настройка производится через интерфейс управления сайтами.
• HAProxy, Nginx (как балансировщик): Поддерживают SNI для маршрутизации трафика на основе имени хоста на уровне TLS.

По типу клиента

• Веб-браузеры: Все современные браузеры (Google Chrome, Mozilla Firefox, Safari, Microsoft Edge) поддерживают SNI.
• Мобильные приложения: Большинство приложений, использующих HTTPS, поддерживают SNI.
• Библиотеки и утилиты: cURL, wget, OpenSSL (с опцией -servername) поддерживают SNI.

Ограничения и проблемы

Несмотря на широкое распространение, SNI имеет ряд ограничений и критических замечаний.

Проблема конфиденциальности

Основной недостаток SNI — передача имени хоста в открытом виде на этапе рукопожатия TLS. Это означает, что любой наблюдатель в сети (провайдер, администратор сети, злоумышленник) может видеть, какие сайты посещает пользователь, даже если само соединение зашифровано. Это делает SNI уязвимым для анализа трафика и цензуры.

Решения для повышения конфиденциальности

• Encrypted Client Hello (ECH): Бывшее расширение TLS 1.3, ранее известное как Encrypted SNI (ESNI). ECH шифрует всё содержимое ClientHello, включая SNI, с помощью публичного ключа сервера. Это предотвращает перехват имени хоста. Однако ECH требует поддержки со стороны сервера и клиента, а также наличия DNS-записей, содержащих ключи шифрования. Внедрение ECH идёт медленно из-за сложности и требований к инфраструктуре.
• TLS 1.3 и ECH: Протокол TLS 1.3 сам по себе не решает проблему SNI, но предоставляет механизмы для ECH.

Проблемы с совместимостью

• Старые клиенты: Некоторые старые версии операционных систем (например, Windows XP, Android до версии 2.3) и браузеры (Internet Explorer на Windows XP) не поддерживают SNI. Для таких клиентов необходимо либо использовать отдельные IP-адреса, либо применять сертификаты с несколькими доменами (SAN), либо использовать специальные серверные решения.
• Серверные решения: Некоторые старые версии серверного ПО (например, Apache до версии 2.2.12) не поддерживали SNI.

Проблемы с сертификатами

• Сертификаты с подстановочными знаками (Wildcard): SNI позволяет использовать сертификаты, действительные для нескольких доменов (например, *.example.com), но сервер должен правильно выбирать сертификат на основе имени.
• Сертификаты с несколькими именами (SAN): Сертификат может содержать несколько доменных имён в поле Subject Alternative Name (SAN). Сервер может использовать один сертификат для нескольких сайтов, если они перечислены в SAN.

Применение

SNI является основой для работы современного интернета, особенно в области хостинга и облачных сервисов.

• Виртуальный хостинг: Позволяет размещать сотни и тысячи сайтов с разными SSL-сертификатами на одном IP-адресе, что существенно снижает затраты на инфраструктуру.
• Балансировка нагрузки: Балансировщики нагрузки (например, HAProxy, Nginx) используют SNI для маршрутизации HTTPS-трафика к соответствующему бэкенд-серверу на основе имени хоста.
• CDN (Content Delivery Network): Сети доставки контента используют SNI для обслуживания множества клиентов с разными доменами на одних и тех же пограничных серверах.
• Прокси-серверы: Прокси-серверы (например, Squid) могут использовать SNI для определения целевого сервера при пересылке HTTPS-запросов.

Интересные факты

• SNI не является обязательным расширением TLS. Клиент может не отправлять SNI, и сервер может принять соединение, используя сертификат по умолчанию.
• В некоторых случаях, например, при использовании технологии Server Name Indication (SNI) в сочетании с протоколом HTTP/2, передача имени хоста может быть дополнительно оптимизирована.
• Существуют реализации SNI, которые позволяют серверу не только выбирать сертификат, но и маршрутизировать запросы к разным приложениям или виртуальным машинам на основе имени хоста.

Источники

• RFC 3546 — Transport Layer Security (TLS) Extensions (2003)
• RFC 6066 — Transport Layer Security (TLS) Extensions: Extension Definitions (2011)
• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 (2018)
• Документация Apache HTTP Server: модуль mod_ssl
• Документация Nginx: модуль ngx_http_ssl_module
• Документация Microsoft IIS: Настройка SNI