Введение
Виртуальный хостинг это практика обслуживания нескольких сайтов на тот же сервер, Хотя сейчас это норма, это было невозможно в первые дни HTTP (версии до 1.1).
Первоначально сервер мог размещать только несколько веб-сайтов на одном компьютере (т.е. под одним и тем же IP-адресом) при условии, что каждому веб-сайту был назначен выделенный порт. Это не было идеальным решением, потому что браузеры по умолчанию используют порт 80 для HTTP, если пользователь не указал другой. В результате большинство владельцев веб-сайтов выбрали выделенный сервер, чтобы избежать риска того, что пользователи не запомнят правильный номер порта и не окажутся на другом веб-сайте.
Тем не менее, по мере того, как все больше пользователей подключалось к Интернету и все больше сетевых устройств начали появляться в сети, количество доступных IP-адресов начало уменьшаться с угрожающей скоростью. Это ожидаемое истощение, известное как Исчерпание диапазона адресов IPv4подтолкнул индустрию к разработке и внедрению различных контрмер, таких как IPv6 (Преемник IPv4), который может поддерживать больше адресов, чем нам когда-либо понадобится, К сожалению, хотя IPv6 является жизнеспособным решением, его внедрение идет довольно медленно. В соответствии с Статистика Google по IPv6На момент написания этой статьи только около 25% интернет-устройств были развернуты через IPv6.
Виртуальный хостинг также был реализован в качестве раннего решения проблемы исчерпания, с введением Host заголовок в HTTP 1.1. Браузеры, обменивающиеся данными по HTTP 1.1, теперь могут подключаться к порту сервера. 80 и включить доменное имя (например, www.ssl.com) веб-сайта, который они хотели посетить в Host заголовок. Независимо от того, сколько сайтов сервер размещает на одном и том же порту, он может использовать эту информацию для определения правильного веб-сайта и возврата его содержимого.
HTTPS и виртуальный хостинг
Однако многочисленные опубликованные отчеты об уязвимостях сети и атаках на веб-пользователей побудили отрасль начать переходить от небезопасного HTTP к его более безопасной альтернативе HTTPS, Широкое принятие HTTPS улучшил общую безопасность пользователей. Однако его дополнительные усовершенствования также увеличили общую сложность веб-коммуникаций.
В принципе, HTTPS очень похож на HTTP, за исключением того, что HTTPS-связь между браузерами и серверами зашифрована. Вкратце, HTTPS требует, чтобы серверы предоставляли браузерам действующий сертификат SSL, выпущенный публично доверенным центр сертификации (CA), такой как SSL.com, Затем браузер может использовать открытый ключ, содержащийся в сертификате, для установить зашифрованный канал связи с сервером. Кроме того, для определенного доменного имени выдается сертификат, который браузер проверяет на соответствие домену, который пользователь хотел посетить. Таким образом, независимо от того, сколько веб-сайтов размещено на сервере, браузеры ожидают найти действительный сертификат SSL для запрашиваемого веб-сайта.
Внимательный читатель может уже почувствовать проблему: браузеру требуется правильный сертификат веб-сайта, чтобы установить зашифрованный канал и отправить Host заголовок, в то время как сервер нуждается в Host заголовок, чтобы найти сертификат правильного сайта. Это классическая проблема курицы и яйца.
Очевидно, что виртуальный хостинг в том виде, как он задумывался для HTTP, не работает для HTTPS, поскольку средства безопасности не позволяют браузерам отправлять Host информация на сервер. Тем не менее, несмотря на то, что проблема исчерпания IPv4 все еще не решена, а в отрасли постоянно растет внедрение облачных технологий (требующих балансировки нагрузки и нескольких резервных внутренних серверов), виртуальный хостинг по-прежнему необходим.
А как насчет многодоменных сертификатов?
Предлагаемое решение этой проблемы - использование многодоменной или Сертификаты SAN. Один сертификат SAN может защитить сотни различных доменных имен, и браузеры не будут жаловаться, если они обнаружат доменное имя, которое они пытаются посетить, в списке доменов сертификата SAN. После настройки зашифрованного канала браузер может отправлять Host заголовок на сервер и продолжайте, как и в любом другом случае. Это отличная идея, в которой используется уже существующая и доступная технология, но те же механизмы, которые обеспечивают безопасность сертификатов SAN, также привели к нескольким потенциально нежелательным побочным эффектам:
Сертификаты SAN являются прекрасным инструментом для защиты нескольких доменов, принадлежащих одному и тому же объекту (человеку, компании или организации), но их несколько непрактично использовать в виртуальном хостинге; всякий раз, когда новый домен готов к добавлению или удалению из сертификата, ЦС должен выдать новый сертификат с последним списком доменов и повторно развернуть его на всех доменах.
Кроме того, сертификаты SAN могут быть выданы только как Подтвержденная организация (OV) или Расширенная подтвержденная (EV) if Найти Домены принадлежат одной организации. Эти уровни проверки относятся к количество и типы информации о предполагаемом владельце сертификата, проверенные ЦС перед выдачей им сертификата. Было показано, что чем выше уровень проверки, тем больше доверия пользователей к веб-сайту, и доверие пользователей может повлиять на узнаваемость бренда и коэффициент конверсии.
Наконец, в среде общего веб-хостинга довольно часто компания делит сервер с другими предприятиями или организациями (даже со своими конкурентами). Поскольку домены в сертификатах SAN находятся в публичном списке, владельцы бизнеса могут неохотно предоставлять тот же сертификат сторонним компаниям.
Хотя сертификаты SAN являются мощным и универсальным инструментом с бесчисленным количеством приложений, эти проблемы побудили IETF - руководящий орган для стандартов Интернета - искать более подходящие подходы к конкретной проблеме виртуально размещенных веб-сайтов HTTPS.
Указание имени сервера для спасения
Решение было реализовано в виде Указание имени сервера (SNI) расширение TLS протокол (часть HTTPS, которая занимается шифрованием).
SNI позволяет браузерам указывать доменное имя, к которому они хотят подключиться во время TLS рукопожатие (первоначальное согласование сертификата с сервером). Как следствие, веб-сайты могут использовать свои собственные сертификаты SSL, но при этом размещаться на общих IP-адресах и портах, поскольку серверы HTTPS могут использовать информацию SNI для идентификации соответствующей цепочки сертификатов, необходимой для установления соединения.
После этого, когда зашифрованный канал связи настроен, браузер может продолжить включение доменного имени веб-сайта в Host заголовок и продолжайте как обычно. По сути, SNI выполняет ту же функцию, что и HTTP. Host заголовок при создании зашифрованного соединения.
Этот простой трюк, наконец, позволил серверам размещать несколько веб-сайтов HTTPS на одном порту. Однако, как и большинство Интернет-технологий, у SNI есть некоторые ограничения.
Проблемы поддержки SNI
Хотя SNI является достаточно зрелым, поскольку он был впервые разработан в 1999 году, все еще существует несколько устаревших браузеров (IE в Windows XP) и операционных систем (версии Android <= 2.3), которые его не поддерживают. Полный список браузеров и операционных систем, поддерживающих SNI, можно найти на этот стол.
Хотя рыночные доли браузеров, которые не поддерживают SNI (и, соответственно, случаев, когда это происходит), ничтожны по сравнению с современными браузерами, если браузер не распознает SNI, он вернется к сертификату SSL по умолчанию и потенциально создаст общая ошибка несоответствия имен.
Многие компании, такие как Google, внедряют SNI для клиентов, которые его поддерживают, и используют редкие случаи, когда этого не происходит. Естественно, эта проблема, как ожидается, будет уменьшаться по мере того, как все больше пользователей и владельцев бизнеса будут обновлять свои системы до современных технологий.
Конфиденциальность SNI
Текущая стабильная версия TLS (версия 1.2) передает начальную часть рукопожатия и, соответственно, информацию SNI в незашифрованном виде. Следовательно, сетевой злоумышленник может обнаружить историю веб-поиска пользователя, несмотря на то, что сами веб-коммуникации полностью зашифрованы.
Различные поставщики облачных услуг, такие как Amazon или Google, допустили (грязный) обходной путь, известный как выход в домен. Фронтинг домена может предотвратить раскрытие истории веб-поиска, поскольку он скрывает информацию SNI, используя имя хоста облачного провайдера в TLS переговоры и целевой сайт в заголовке HTTP. Однако этот метод больше не работает, поскольку Google и Amazon публично заявили, что они отключена поддержка фронтинга домена в их услугах по состоянию на апрель 2018 года.
К счастью, было предложено более системное решение. экспериментальный проект детализация Зашифрованный SNI (ЕСНИ) расширение для новейших TLS версия, 1.3. ESNI шифрует информацию SNI, тем самым смягчая все проблемы конфиденциальности. К сожалению, TLS 1.3 еще не получил широкого распространения в отрасли, хотя TLS 1.3 постепенно становится протоколом сетевой безопасности де-факто, Следите за нашими будущими статьями о состоянии ESNI и конфиденциальности HTTPS и TLS.
Заключение
Таким образом, SNI позволяет размещать миллионы веб-сайтов HTTPS на одном сервере. Однако, в зависимости от вашего индивидуального случая, сертификат SAN может работать лучше для вас. Проблемы конфиденциальности в отношении SNI все еще существуют, хотя также существует потенциальное решение с ESNI. В любом случае, используя один или комбинацию этих двух методов, вы можете легко реализовать виртуальный хостинг для всех ваших сайтов с минимальными усилиями.
Если у вас есть дополнительные вопросы о SNI или вы не знаете, как выбрать между SAN и SNI, мы всегда рады ответить на все вопросы наших клиентов об их PKI необходимо. Просто напишите нам по электронной почте на support@ssl.com и специалист поможет вам
