Server Name Indication

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Для термина «SNI» см. также другие значения.

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, не подвержены этой проблеме.

Блокировка ESNI

[править | править код]

С августа 2020 в Китае блокируется ESNI и TLSv1.3 трафик т.к. не позволяет функционировать DPI «Золотого щита».[10].

Примечания

[править | править код]
  1. ↑ «Server Name Indication 889». RFC 3546 (англ.)
  2. ↑ TLS Server Name Indication. Paul's Journal. Дата обращения: 13 ноября 2015. Архивировано 12 августа 2016 года.
  3. ↑ draft-ietf-tls-esni-07 - Encrypted Server Name Indication for TLS 1.3
  4. ↑ Ghedini, Alessandro (2018-09-24). "Encrypt it or lose it: how encrypted SNI works". Cloudflare blog (англ.). Архивировано 24 сентября 2018. Дата обращения: 19 января 2019. ([1] Архивная копия от 19 января 2019 на Wayback Machine)
  5. ↑ "Encrypted SNI Comes to Firefox Nightly". Mozilla blog (англ.). 2018-10-18. Архивировано 24 марта 2020. Дата обращения: 19 января 2019. ([2] Архивная копия от 20 января 2019 на Wayback Machine)
  6. ↑ ESNI: A Privacy-Protecting Upgrade to HTTPS. EFF DeepLinks Blog. Дата обращения: 19 января 2019. Архивировано 18 мая 2019 года.
  7. ↑ Claburn, Thomas (2018-07-17). "Don't panic about domain fronting, an SNI fix is getting hacked out". The Register. Архивировано 26 августа 2018. Дата обращения: 10 октября 2018.
  8. ↑ VhostTaskForce - CAcert Wiki. wiki.cacert.org. Дата обращения: 19 января 2019. Архивировано 31 декабря 2018 года.
  9. ↑ Что такое многодоменный сертификат SSL (UCC)? | Сертификаты SSL - Справка GoDaddy RU. ru.godaddy.com. Дата обращения: 19 января 2019. Архивировано 19 января 2019 года.
  10. ↑ Catalin Cimpanu. China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI (англ.). ZDNet. Дата обращения: 29 октября 2020. Архивировано 9 августа 2020 года.
Источник — https://ru.wikipedia.org/w/index.php?title=Server_Name_Indication&oldid=140084865