Server Name Indication

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Server Name Indication (SNI) — расширение компьютерного протокола TLS[1], которое позволяет клиентам сообщать имя хоста, с которым он желает соединиться во время процесса «рукопожатия». Это позволяет серверу предоставлять несколько сертификатов на одном IP-адресе и TCP-порту, и, следовательно, позволяет работать нескольким безопасным (HTTPS) сайтам (или другим сервисам поверх TLS) на одном IP-адресе без использования одного и того же сертификата на всех сайтах. Это эквивалентно возможности основанного на имени виртуального хостинга из HTTP/1.1. Запрашиваемое имя хоста не шифруется,[2] что позволяет злоумышленнику его перехватить.

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

С осени 2018 года проводятся эксперименты по внедрению Encrypted SNI[3] из протокола TLS 1.3, который шифрует имя запрашиваемого сайта с помощью публичного ключа сайта, получаемого из системы имен DNS[4][5][6][7].

Предпосылки проблемы[править | править код]

В ходе создания TLS подключения клиент запрашивает цифровой сертификат у web-сервера; после того, как сервер отправляет сертификат, клиент проверяет его действительность и сравнивает имя, с которым он пытался подключиться к серверу, с именами, содержащимися в сертификате. Если сравнение успешно, происходит соединение в зашифрованном режиме. Если совпадений не найдено, пользователь может быть предупреждён о несоответствии и соединение прерывается, так как несоответствие может свидетельствовать о попытке совершения атаки «человек посередине». Однако некоторые приложения позволяют пользователю проигнорировать предупреждение для продолжения соединения, перекладывая на пользователя вопрос о доверии сертификату и, соответственно, подключение к сайту.

Однако может быть трудно — или даже невозможно из-за отсутствия заранее заготовленного полного списка всех имен — получить единый сертификат, который охватывает все имена, за которые будет отвечать сервер. Сервер, отвечающий за несколько имен хостов, вероятно, должен будет представить разные сертификаты для каждого имени (или небольшой группы имен). С 2005 года CAcert проводит эксперименты по различным методам использования TLS на виртуальных серверах.[8] Большинство экспериментов являются неудовлетворительными и непрактичными. Например, можно использовать subjectAltName для хранения нескольких доменов, контролируемых одним человеком[9] в одном сертификате. Такие «унифицированныe сертификаты» необходимо переиздавать каждый раз, когда меняется список доменов.

Виртуальный хостинг на основе имен позволяет размещать несколько имен хостов на одном сервере (обычно на веб-сервере) на одном IP-адресе. Чтобы добиться этого, сервер использует имя хоста, представленное клиентом как часть протокола (для HTTP имя представлено в заголовке Host). Однако при использовании HTTPS рукопожатие TLS происходит до того, как сервер увидит какие-либо HTTP-заголовки. Следовательно, сервер не может использовать информацию в HTTP заголовке host, чтобы решить, какой сертификат представлять, и соответственно только имена, прописанные в одном сертификате, могут обслуживаться на одном IP-адресе.

На практике это означает, что сервер HTTPS может обслуживать только один домен (или небольшую группу доменов) на одном IP-адресе для безопасного и эффективного просмотра. Назначение отдельного IP-адреса для каждого сайта увеличивает стоимость хостинга, поскольку запросы на IP-адреса должны быть обоснованы в региональном интернет-регистраторе, а адреса IPv4 уже исчерпаны. В результате многие веб-сайты фактически не могут использовать безопасный протокол при использовании IPv4. Адресное пространство IPv6 не исчерпано, поэтому веб-сайты, обслуживаемые по протоколу IPv6, не подвержены этой проблеме.

Примечания[править | править код]

  1. «Server Name Indication». RFC 3546 (англ.)
  2. TLS Server Name Indication. Paul's Journal.
  3. https://tools.ietf.org/html/draft-ietf-tls-esni
  4. Ghedini, Alessandro. Encrypt it or lose it: how encrypted SNI works (англ.), Cloudflare blog (24 September 2018). Дата обращения 19 января 2019. ([1])
  5. Encrypted SNI Comes to Firefox Nightly (англ.), Mozilla blog (18 October 2018). Дата обращения 19 января 2019. ([2])
  6. ESNI: A Privacy-Protecting Upgrade to HTTPS. EFF DeepLinks Blog.
  7. Don't panic about domain fronting, an SNI fix is getting hacked out, The Register (17 July 2018). Дата обращения 10 октября 2018.
  8. VhostTaskForce - CAcert Wiki. wiki.cacert.org. Дата обращения 19 января 2019.
  9. Что такое многодоменный сертификат SSL (UCC)? | Сертификаты SSL - Справка GoDaddy RU. ru.godaddy.com. Дата обращения 19 января 2019.