Сайт SSL по умолчанию не поддерживает браузеры без функций sni

Обновлено: 03.07.2024

Server Name Indication (SNI) — это расширение для протокола SSL/TLS. Это расширение позволяет клиенту распознавать подключающееся имя хоста во время процесса рукопожатия.

Соединение TLS или процесс рукопожатия SSL основан на сертификате и доменном имени, для которого он выдан. Когда клиент обращается к веб-сайту, клиент делает запрос на цифровой сертификат. Сервер в ответ отправляет сертификат сервера; затем клиент проверяет имя сертификата и имя домена, к которому он пытается подключиться. Если оба имени (имя сертификата и имя, введенное в браузере) совпадают, то соединение будет установлено. Напротив, он покажет предупреждающее сообщение о неудачном соединении. Несовпадающее соединение указывает на атаку «человек посередине». Многие пользователи игнорируют это предупреждение, чтобы продолжить подключение.

Чтобы решить эту проблему, SSL-сертификат указывает на IP-адрес. Веб-серверы, использующие IP-адрес, могут распознать, к какой веб-странице браузер хочет подключиться, и затем сервер отправляет правильный сертификат.

Проблема нескольких IP-адресов

С ростом количества IP-адресов это стало проблемой, поскольку каждому веб-сайту потребуется уникальный IP-адрес. Это увеличит стоимость хостинга в долгосрочной перспективе и будет сложно обрабатывать несколько IP-адресов. Кроме того, SSL поддерживает функции SAN и Wildcard, поэтому серверу стало сложно, так как он должен иметь разные сертификаты для каждого имени. Наконец, форум CA/Browser решил ввести SNI (указание имени сервера).

Что такое SNI (индикация имени сервера)?

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

Браузеры будут иметь дело с точным доменным именем, к которому посетитель хочет подключиться во время защищенного SSL-рукопожатия. Следовательно, сервер очень хорошо знает, какой сертификат права он должен отправить обратно клиенту. В этом случае сервер, использующий один IP-адрес, может обслуживать несколько доменных имен, для которых недостаточно приобрести один сертификат.

SNI позволяет серверу использовать разные SSL-сертификаты по одному и тому же IP-адресу. Поэтому он обслуживает правильные сертификаты для этих веб-сайтов и предоставляет защищенный сайт клиенту. Каждый сертификат привязан к определенному полному доменному имени, и с помощью SNI сервер выбирает правильный сертификат для определенного доменного имени.

Какие браузеры поддерживают SNI?

Многие старые браузеры не поддерживают функцию SNI, в то время как современные браузеры и серверы поддерживают SNI. Ниже приведен список версий браузеров и серверов, необходимых для поддержки функции SNI.

Internet Explorer 7 и более поздние версии в Windows Vista и более поздних версиях
Internet Explorer (любая версия) в Windows XP не поддерживает SNI
Mozilla Firefox 2.0 и более поздние версии
Opera 8.0 (2005) и более поздние версии
Должен быть включен протокол TLS 1.1
Google Chrome:
Поддерживается в Windows Vista и более поздних версиях
Поддерживается в Windows XP в Chrome 6 и более поздних версиях
Поддерживается в OS X 10.5.7 в Chrome v5.0.342.1 и более поздних версиях< /li>
Safari 2.1 и более поздних версий
Поддерживается в OS X 10.5.6 и более поздних версиях
Поддерживается в Windows Vista и более поздних версиях

Mobile Safari для iOS 4. и более поздних версий
Браузер Android по умолчанию для Honeycomb (v3.x) и более поздних версий
Windows Phone 7

Использование SNI зависит от клиентов и обновленного статуса их устройств. Без SNI один IP-адрес может управлять одним именем хоста. Раньше владелец веб-сайта должен был платить за IP-адрес, но с SNI организации не нужно тратить дополнительные деньги, и одного IP-адреса достаточно для нескольких имен хостов.

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

Как это работало до внедрения SNI

Когда кто-то посещает ваш веб-сайт, его веб-браузер/клиент подключается к веб-серверу и отправляет ему имя и доменное имя веб-страницы.При создании соединения SSL/TLS процесс становится немного сложнее. Браузер потребует от сервера цифровой сертификат еще до того, как узнает, к какой странице браузер хочет получить доступ. Затем он сравнивает имя в сертификате с сервера с именем страницы, с которой пытается установить соединение.

Если имена совпадают, подключение будет выполнено обычным способом.

Если имена не совпадают, посетитель не увидит ваш веб-сайт, а увидит предупреждающее сообщение, за которым, возможно, последует отключение от веб-сайта, поскольку неудачное соединение может указывать на атаку посредника.

Чтобы предотвратить это, веб-сайты, использующие SSL, должны иметь собственные IP-адреса. Это позволяет веб-серверу использовать IP-адрес, чтобы проверить, к какому веб-сайту хочет подключиться посетитель, и отправить правильный сертификат браузеру или клиенту.

SNI как решение

Поскольку количество IP-адресов ограничено, требование, чтобы каждый веб-сайт имел собственный IP-адрес, может вызвать проблемы в долгосрочной перспективе. Индикация имени сервера (SNI) является решением этой проблемы. Браузеры, поддерживающие SNI, немедленно сообщат имя веб-сайта, к которому посетитель хочет подключиться, во время инициализации защищенного соединения, чтобы сервер знал, какой сертификат отправить обратно. Это позволяет браузерам/клиентам и серверам, поддерживающим SNI, подключать несколько сертификатов для нескольких доменов к одному IP-адресу. Так что посетитель вашего сайта не заметит никаких отличий.

< /p>

Технология SNI довольно новая. Его реализация проходила с 2004 по 2007 год.

Для реализации этой технологии библиотека TLS приложения должна включать SNI, и это приложение должно передавать имя хоста в библиотеку TLS.

Кроме того, библиотека TLS может быть либо включена в прикладную программу, либо быть компонентом рассматриваемой операционной системы. Из-за этой проблемы некоторые браузеры реализуют SNI при работе в любой операционной системе, в то время как другие реализуют его только при работе в определенных операционных системах.

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

Приложения, поддерживающие SNI

Веб-браузеры

Internet Explorer 7 или более поздней версии, в Windows Vista или более поздней версии.
Mozilla Firefox 2.0 или более поздней версии
Opera 8.0 (2005) или более поздней версии (должен быть включен протокол TLS 1.1)
Opera Mobile, бета-версия не ниже 10.1 для Android
Google Chrome (Vista или выше. XP в Chrome 6 или новее, OS X 10.5.7 или выше в Chrome 5.0.342.1 или новее)
Safari 3.0 или более поздней версии (Mac OS X 10.5.6 или более поздней версии и Windows Vista или более поздней версии)
Konqueror/KDE 4.7 или новее
MobileSafari в Apple iOS 4.0 или более поздней версии
Браузер Android по умолчанию для Honeycomb (v3.x) или новее
Браузер по умолчанию для BlackBerry 10 и BlackBerry Tablet OS
Windows Phone 7 или более поздней версии
MicroB на Maemo
Одиссея на MorphOS

Серверы

Библиотеки

Mozilla NSS 3.11.1 только на стороне клиента
OpenSSL
- 0.9.8f (выпущена 11 октября 2007 г.) – не скомпилирована по умолчанию, ее можно скомпилировать с помощью параметра конфигурации --enable-tlsext.
- 0.9.8j (выпущено 07 января 2009 г.) — 1.0.0 (выпущено 29 марта 2010 г.) — скомпилировано по умолчанию.
Как настроить SNI

Для Tomcat SNI не поддерживается на стороне сервера до Java 8. Минимальная версия Java, которую должен поддерживать Tomcat 8, — это Java 7, поэтому на данный момент в Tomcat нет поддержки SNI. Возможна дополнительная поддержка SNI, если Tomcat работает на Java 8 или более поздней версии, но для этого потребуются изменения кода, которые пока не запланированы.

Подробные сведения о поддержке клиентов, не поддерживающих SNI, с прокси-сервером веб-приложения и AD FS 2012 R2 можно найти здесь.

Сертификат сервера является общедоступным объектом. Он отправляется каждому клиенту, который подключается к серверу NGINX или NGINX Plus. Закрытый ключ является безопасным объектом и должен храниться в файле с ограниченным доступом. Однако главный процесс NGINX должен иметь возможность прочитать этот файл. Кроме того, закрытый ключ можно хранить в том же файле, что и сертификат:

В этом случае важно ограничить доступ к файлу. Обратите внимание, что хотя в этом случае сертификат и ключ хранятся в одном файле, клиентам отправляется только сертификат.

Директивы ssl_protocols и ssl_ciphers можно использовать, чтобы потребовать, чтобы клиенты использовали только надежные версии и шифры SSL/TLS при установлении соединений.

Начиная с версии 1.9.1, NGINX использует следующие значения по умолчанию:

Иногда в конструкции старых шифров обнаруживаются уязвимости, и мы рекомендуем отключать их в современной конфигурации NGINX (к сожалению, конфигурацию по умолчанию нелегко изменить из-за обратной совместимости с существующими развертываниями NGINX). Обратите внимание, что шифры в режиме CBC могут быть уязвимы для ряда атак (в частности, атаки BEAST, описанной в CVE-2011-3389), и мы рекомендуем не использовать SSLv3 из-за атаки POODLE, если только вам не требуется поддержка устаревших клиентов. .

Проверка сертификатов клиентов OCSP

NGINX можно настроить для использования протокола статуса онлайн-сертификатов (OCSP) для проверки действительности клиентских сертификатов X.509 по мере их предоставления. Запрос OCSP на статус сертификата клиента отправляется ответчику OCSP, который проверяет действительность сертификата и возвращает ответ со статусом сертификата:
- Хорошо — сертификат не отозван
- Revoked — сертификат отозван
- Неизвестно: информация о сертификате клиента отсутствует
Чтобы включить проверку OCSP клиентских сертификатов SSL, укажите директиву ssl_ocsp вместе с директивой ssl_verify_client, которая включает проверку сертификата:

Чтобы кэшировать ответы OCSP в одной зоне памяти, совместно используемой всеми рабочими процессами, укажите директиву ssl_ocsp_cache, чтобы определить имя и размер зоны. Ответы кэшируются на 1 час, если только значение nextUpdate в ответе OCSP не указывает другое значение:

Результат проверки сертификата клиента доступен в переменной $ssl_client_verify, включая причину сбоя OCSP.

Операции SSL потребляют дополнительные ресурсы ЦП. Наиболее ресурсоемкой операцией является рукопожатие SSL. Есть два способа минимизировать количество этих операций на одного клиента:
- Включение активных подключений для отправки нескольких запросов через одно подключение
- Повторное использование параметров сеанса SSL, чтобы избежать рукопожатий SSL для параллельных и последующих подключений.
Сеансы хранятся в кэше сеансов SSL, совместно используемом рабочими процессами и настраиваемом директивой ssl_session_cache. Один мегабайт кеша содержит около 4000 сессий. Время ожидания кэша по умолчанию составляет 5 минут. Это время ожидания можно увеличить с помощью директивы ssl_session_timeout. Ниже приведен пример конфигурации, оптимизированной для многоядерной системы с 10-мегабайтным общим кэшем сеанса:

Цепочки сертификатов SSL

Некоторые браузеры могут жаловаться на сертификат, подписанный известным центром сертификации, в то время как другие браузеры могут принять сертификат без проблем. Это происходит из-за того, что выдавший сертификат подписал сертификат сервера с помощью промежуточного сертификата, которого нет в базе известных доверенных центров сертификации, распространяемой в том или ином браузере. В этом случае центр предоставляет пакет связанных сертификатов, которые должны быть объединены с подписанным сертификатом сервера. Сертификат сервера должен стоять перед цепочками сертификатов в объединенном файле:

Полученный файл следует использовать в директиве ssl_certificate:

Если сертификат сервера и пакет были объединены в неправильном порядке, NGINX не запускается и отображает следующее сообщение об ошибке:

Ошибка возникает из-за того, что NGINX пытается использовать закрытый ключ с первым сертификатом пакета вместо сертификата сервера.

Браузеры обычно хранят промежуточные сертификаты, которые они получают и подписывают доверенные центры. Таким образом, активно используемые браузеры могут уже иметь необходимые промежуточные сертификаты и могут не жаловаться на сертификат, отправленный без связанного пакета. Чтобы убедиться, что сервер отправляет полную цепочку сертификатов, можно использовать утилиту командной строки openssl:

Сертификат SSL с несколькими именами

Индикация имени сервера
- Опера 8.0
- MSIE 7.0 (но только в Windows Vista или выше)
- Firefox 2.0 и другие браузеры, использующие платформу Mozilla Platform rv:1.8.1
- Safari 3.2.1 (версия для Windows поддерживает SNI в Vista и выше)
- Chrome (версия для Windows также поддерживает SNI в Vista и выше)
В SNI можно передавать только доменные имена. Однако некоторые браузеры будут передавать IP-адрес сервера в качестве его имени, если запрос включает буквальный IP-адрес. На это лучше не полагаться.

Чтобы использовать SNI в NGINX, он должен поддерживаться как в библиотеке OpenSSL, с которой был создан двоичный файл NGINX, так и в библиотеке, с которой он динамически связывается во время выполнения. OpenSSL поддерживает SNI, начиная с версии 0.9.8f, если он был собран с параметром конфигурации --enable-tlsext. Начиная с версии OpenSSL 0.9.8j, этот параметр включен по умолчанию. Если NGINX был собран с поддержкой SNI, NGINX показывает следующее при запуске с ключом -V:

Однако, если NGINX с поддержкой SNI динамически связан с библиотекой OpenSSL без поддержки SNI, NGINX отображает предупреждение:

Примечания о совместимости

Статус поддержки SNI показывался с помощью ключа -V, начиная с версий 0.8.21 и 0.7.62.

Параметр ssl директивы listen поддерживается, начиная с версии 0.7.14. До версии 0.8.21 его можно было указать только вместе с параметром по умолчанию.

SNI поддерживается с версии 0.5.23.

Общий кэш сеанса SSL поддерживается, начиная с версии 0.5.6.

Версия 1.9.1 и более поздние: протоколы SSL по умолчанию — TLSv1 , TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).

Начиная с версий 0.7.65 и 0.8.19 и более поздних, протоколами SSL по умолчанию являются SSLv3 , TLSv1 , TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).

В версиях 0.7.64 и 0.8.18 и более ранних протоколами SSL по умолчанию являются SSLv2 , SSLv3 и TLSv1 .

В версии 1.0.5 и более поздних версиях шифры SSL по умолчанию: HIGH:!aNULL:!MD5 .

В версиях 0.7.65 и 0.8.20 и более поздних версиях SSL по умолчанию используются шифры HIGH:!ADH:!MD5 .

Начиная с версии 0.8.19 шифры SSL по умолчанию: ВСЕ:!ADH:RC4+RSA:+HIGH:+MEDIUM .

Начиная с версии 0.7.64, 0.8.18 и более ранних шифров SSL по умолчанию: ВСЕ:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP .

США Доллар Евро Британский фунт Канадские доллары Австралийские доллары Индийские рупии Китайский юань Юань Подробнее →

Мы поддерживаем наших друзей и коллег в Украине. Чтобы поддержать Украину в трудную минуту, посетите эту страницу.

Настройка клиентов без SNI на сервере Windows

В настоящее время обычной практикой является размещение нескольких веб-сайтов на одном сервере с одним и тем же IP-адресом. В таких случаях и клиент, и сервер должны поддерживать технологию Server Name Indication (SNI) для запроса и получения соответствующего сертификата, выданного для домена. SNI полагается на то, что клиент отправляет заголовок ServerName во время рукопожатия SSL, что означает, что клиенту необходимо поддерживать SNI. Хотя большинство современных приложений настроены для работы с SNI, для поддержки старых/устаревших клиентов потребуется дополнительная настройка.

В этой статье рассматривается поддержка клиентов, не совместимых с SNI, в Windows Server.

Примечание. Список браузеров, поддерживающих SNI, можно найти здесь.

Поддержка SNI была добавлена в Microsoft IIS, начиная с IIS 8.0. Требовать указание имени сервера — это параметр в привязке веб-сайта, который позволяет привязывать несколько сертификатов к разным веб-сайтам с одним и тем же IP-адресом:

Соединение с SNI

Ниже вы можете увидеть пример соединения SSL с заголовком ServerName. Сервер проверяет заголовок и отправляет правильный сертификат:

Подключение без SNI

Вот пример подключения SSL к тому же серверу без заголовка ServerName. Обратите внимание, что сервер не отправляет сертификат:

Вы можете проверить свойства сертификата с помощью оснастки "Сертификаты" в MMC. Отпечаток можно найти, прокрутив вниз вкладку «Подробности»:

Выполнение команды в PowerShell

В итоге команда будет выглядеть примерно так:

После ввода сервер подтвердит добавление привязки:

С этого момента сертификат будет использоваться, если клиент не указал ServerName:

Читайте также: