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

Блокировка ESNI

С августа 2020 в Китае блокируется ESNI- и TLSv1.3-трафик[10].

С октября 2020 и ранее в России провайдеры так же начали блокировку ESNI-трафика, что в итоге делает обычные и не запрещенные сайты недоступными для пользователей, учитывая что никаких действующих законов о блокировке этой технологии нет[11]. Первыми блокирующими ESNI провайдерами стали Ростелеком и затем - его дочерняя компания ООО «Т2 РТК Холдинг» (торговая марка «Tele2 Россия»).

Примечания
  1. «Server Name Indication 889». RFC 3546 (англ.)
  2. TLS Server Name Indication. Paul's Journal.
  3. draft-ietf-tls-esni-07 - Encrypted Server Name Indication for TLS 1.3
  4. Ghedini, Alessandro. Encrypt it or lose it: how encrypted SNI works (англ.), Cloudflare blog (24 September 2018). Дата обращения 19 января 2019. ()
  5. Encrypted SNI Comes to Firefox Nightly (англ.), Mozilla blog (18 October 2018). Дата обращения 19 января 2019. ()
  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.
  10. Catalin Cimpanu. China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI (англ.). ZDNet. Дата обращения: 29 октября 2020.
  11. Почему Ростелеком блокирует ESNI трафик?. Хабр Q&A — вопросы и ответы. Дата обращения: 29 октября 2020.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.