No Use for a Name
- 1 year ago
- 0
- 0
Server Name Indication ( SNI ) — расширение компьютерного протокола TLS , которое позволяет клиенту сообщать , с которым он желает соединиться во время процесса «рукопожатия». Это позволяет серверу предоставлять несколько сертификатов на одном IP-адресе и TCP-порту, и, следовательно, позволяет работать нескольким безопасным ( HTTPS ) сайтам (или другим сервисам поверх TLS) на одном IP-адресе без использования одного и того же сертификата на всех сайтах. Это эквивалентно возможности основанного на имени виртуального хостинга из HTTP/1.1. Запрашиваемое имя хоста не шифруется , что позволяет злоумышленнику его перехватить.
Для практического использования SNI требуется, чтобы подавляющее большинство пользователей использовало браузеры с поддержкой этой функции. Пользователи, браузеры которых не поддерживают SNI, получат сертификат по умолчанию (зависит от реализации, обычно первый в списке), и, следовательно, ошибку сертификата, если сервер не оснащён и он не содержит требуемого клиентом имени сайта.
С осени 2018 года проводятся эксперименты по внедрению Encrypted SNI из протокола TLS 1.3, который шифрует имя запрашиваемого сайта с помощью публичного ключа сайта, получаемого из системы имен DNS .
В ходе создания TLS-подключения клиент запрашивает цифровой сертификат у web-сервера; после того, как сервер отправляет сертификат, клиент проверяет его действительность и сравнивает имя, с которым он пытался подключиться к серверу, с именами, содержащимися в сертификате. Если сравнение успешно, происходит соединение в зашифрованном режиме. Если совпадений не найдено, пользователь может быть предупреждён о несоответствии и соединение прерывается, так как несоответствие может свидетельствовать о попытке совершения атаки «человек посередине» . Однако некоторые приложения позволяют пользователю проигнорировать предупреждение для продолжения соединения, перекладывая на пользователя вопрос о доверии сертификату и, соответственно, подключение к сайту.
Однако может быть трудно — или даже невозможно из-за отсутствия заранее заготовленного полного списка всех имен — получить единый сертификат, который охватывает все имена, за которые будет отвечать сервер. Сервер, отвечающий за несколько имен хостов, вероятно, должен будет представить разные сертификаты для каждого имени (или небольшой группы имен). С 2005 года CAcert проводит эксперименты по различным методам использования TLS на виртуальных серверах . Большинство экспериментов является неудовлетворительным и непрактичным. Например, можно использовать subjectAltName для хранения нескольких доменов, контролируемых одним человеком в одном сертификате. Такие «унифицированныe сертификаты» необходимо переиздавать каждый раз, когда меняется список доменов.
Виртуальный хостинг на основе имен позволяет размещать несколько имен хостов на одном сервере (обычно на веб-сервере) на одном IP-адресе. Чтобы добиться этого, сервер использует имя хоста, представленное клиентом как часть протокола (для HTTP имя представлено в заголовке Host ). Однако при использовании HTTPS рукопожатие TLS происходит до того, как сервер увидит какие-либо HTTP-заголовки. Следовательно, сервер не может использовать информацию в HTTP-заголовке host, чтобы решить, какой сертификат представлять, и соответственно только имена, прописанные в одном сертификате, могут обслуживаться на одном IP-адресе.
На практике это означает, что сервер HTTPS может обслуживать только один домен (или небольшую группу доменов) на одном IP-адресе для безопасного и эффективного просмотра. Назначение отдельного IP-адреса для каждого сайта увеличивает стоимость хостинга, поскольку запросы на IP-адреса должны быть обоснованы в региональном интернет-регистраторе , а адреса IPv4 уже исчерпаны . В результате многие веб-сайты фактически не могут использовать безопасный протокол при использовании IPv4. Адресное пространство IPv6 не исчерпано, поэтому веб-сайты, обслуживаемые по протоколу IPv6, не подвержены этой проблеме.
С августа 2020 в Китае блокируется ESNI и TLSv1.3 трафик .