Вопрос: Несколько доменов SSL на одном и том же IP-адресе и том же порту?


Это Канонический вопрос о размещении нескольких сайтов SSL на одном IP-адресе.

У меня сложилось впечатление, что каждый сертификат SSL требовал наличия собственной уникальной комбинации IP-адресов / портов. Но ответ на предыдущий вопрос, который я опубликовал противоречит этому утверждению.

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

Я подозрительно, что сделал что-то не так. Можно ли использовать несколько SSL-сертификатов таким образом?


105
2018-02-04 22:36


Источник


Этот орган Q говорит о нескольких сертификатах, и ответы верны для этого. Но название говорит о нескольких доменах, и вы может иметь несколько доменов с одним сертификатом (и нет SNI), см. serverfault.com/questions/126072/... а также serverfault.com/questions/279722/... тоже крест на безопасность.SX. - dave_thompson_085


Ответы:


Для получения самой последней информации об Apache и SNI, включая дополнительные HTTP-специфические RFC, пожалуйста, обратитесь к Википедия


FYsI: «Несколько (разных) SSL-сертификатов на одном IP-адресе» приносит вам волшебство TLS Upgrading. Он работает с более новыми серверами Apache (2.2.x) и достаточно современными браузерами (не знаю версий с верхней части моей головы).

RFC 2817 (обновление до TLS в HTTP / 1.1) имеет подробные сведения, но в основном это работает для многих людей (если не большинства).
Вы можете воспроизвести старое напуганное поведение с помощью openssl's s_client команда (или любой «старый достаточно» браузер).

Изменить для добавления: очевидно curl может показать вам, что здесь происходит лучше, чем openssl:


SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

67
2018-02-04 23:46



Это очень полезно - Спасибо! Любая информация о том, как настроить Apache для TLS вместо SSL? - Josh
Я думаю, что Apache 2.2 просто должен иметь бит TLS в списке cypher. Я признаю, что я никогда не видел, чтобы бит «Обновление с SSL на TLS» работал до этих двух сайтов. Мое понимание документов TLS заключается в том, что это допустимая (но необычная) ситуация для согласования такого рода обновления ... - voretaq7
Это первый раз, когда я когда-либо видел это, и я все еще пытаюсь вытащить свою челюсть с пола ... - Josh
ОК, мой ответ только утроился по длине. Очевидно, завиток может вести переговоры как по протоколу SSLv3, так и по TLSv1, поэтому я могу показать неудачу и успех. Мне жаль, что у меня не было отладчика протокола, чтобы показать волшебную часть. (Также проверено и рада сообщить, что сервер johnlai2004 правильно отрицает соединения SSLv2 :-) - voretaq7
Это очень полезно, и я надеюсь, что johnlai2004 примет ваш ответ. Большое спасибо! - Josh


Да, но есть некоторые оговорки.

Это выполняется с помощью указания имени сервера, расширения для безопасности транспортного уровня.

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

Индикация имени сервера (RFC 6066; устарела RFC 4366, RFC 3546) является расширением Безопасность транспортного уровня который позволяет клиенту сообщать серверу имя хоста, к которому он пытается связаться.

SNI совместим с TLS 1.0 и выше в соответствии со спецификацией, но реализации могут отличаться (см. Ниже). Он не может использоваться с SSL, поэтому соединение должно согласовывать TLS (см. Приложение RFC 4346 E) для использования SNI. Обычно это происходит автоматически с поддерживаемым программным обеспечением.

Почему нужен СНИ?

В нормальном HTTP соединение, браузер сообщает серверу имени хоста сервера, с которым он пытается связаться, используя Host: заголовок. Это позволяет веб-серверу на одном IP-адресе обслуживать контент для нескольких имен хостов, который обычно известен как виртуальный хостинг на основе имен,

Альтернативой является назначение уникальных IP-адресов для каждого обслуживаемого веб-хоста. Это обычно делалось в самые ранние дни Интернета, прежде чем стало известно, что IP-адреса будут исчерпаны, и меры по сохранению начались, и все еще делается таким образом для виртуальных хостов SSL (не используя SNI).

Поскольку этот способ передачи имени хоста требует установления соединения, он не работает с соединениями SSL / TLS. К моменту установления безопасного соединения веб-сервер уже должен знать, какое имя хоста будет обслуживать клиент, потому что сам веб-сервер настраивает безопасное соединение.

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

Почему бы не использовать разные IP-адреса?

Протокол HTTP Host: заголовок, который позволяет обслуживать более одного веб-хоста от одного IP-адреса из-за нехватки адресов IPv4, признанных в качестве проблемы уже в середине 1990-х годов. В общедоступных средах веб-хостинга сотни уникальных несвязанных веб-сайтов могут быть использованы с использованием одного IP-адреса таким образом, сохраняя адресное пространство.

Затем в общих средах хостинга выяснилось, что крупнейшим потребителем пространства IP-адресов является необходимость обеспечения безопасных веб-сайтов уникальными IP-адресами, что создает потребность в SNI в качестве меры блокировки на пути к IPv6. Сегодня бывает сложно получить всего 5 IP-адресов (29) без существенного обоснования, что часто приводит к задержкам развертывания.

С появлением IPv6 такие методы сохранения адресов больше не нужны, поскольку один хост может иметь больше назначенных ему IPv6-адресов, чем сегодня весь Интернет, но методы, вероятно, все еще будут использоваться далеко в будущем для обслуживания устаревшего IPv4 соединения.

Предостережения

Некоторые комбинации операционной системы / браузера не поддерживают SNI (см. Ниже), поэтому использование SNI не подходит для всех ситуаций. Сайтам, нацеленным на такие комбинации систем / браузеров, пришлось бы отказаться от SNI и продолжать использовать уникальные IP-адреса для каждого виртуального хоста.

Особо следует отметить, что ни одна версия Internet Explorer в Windows XP не поддерживает SNI. Поскольку эта комбинация по-прежнему представляет собой значительную (но неуклонно уменьшающуюся, около 16% интернет-трафика в декабре 2012 года по NetMarketShare) часть интернет-трафика, SNI будет неприемлемым для сайта, ориентированного на эти группы пользователей.

Поддержка

Многие, но не все, обычно используемые пакеты программного обеспечения поддерживают SNI.

(Отсутствие в этом списке необязательно означает отсутствие поддержки, это означает, что существует ограничение на то, как я могу печатать, или я не мог быстро найти информацию в поиске. Если ваш пакет программного обеспечения отсутствует в списке, поиск для его имени плюс sni должен показать, существует ли поддержка и как ее настроить.)

Поддержка библиотек

Большинство пакетов зависят от внешней библиотеки для поддержки SSL / TLS.

  • GNU TLS
  • JSSE (Oracle Java) 7 или выше, только как клиент
  • libcurl 7.18.1 или выше
  • NSS 3.1.1 или выше
  • OpenSSL 0.9.8j или выше
    • OpenSSL 0.9.8f или выше, с настройками флагов
  • Qt 4,8 или выше

Поддержка серверов

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

Поддержка клиентов

Большинство современных веб-браузеров и пользовательских агентов командной строки поддерживают SNI.

рабочий стол

  • Chrome 5 или выше
    • Chrome 6 или выше в Windows XP
  • Firefox 2 или выше
  • Internet Explorer 7 или выше, работающий в Windows Vista / Server 2008 или выше
    • Internet Explorer в Windows XP не поддерживает SNI независимо от версии IE
  • Konqueror 4.7 или новее
  • Opera 8 или выше (может потребоваться включить TLS 1.1)
  • Safari 3.0 на Windows Vista / Server 2008 или выше или Mac OS X 10.5.6 или выше

мобильный

  • Android-браузер на 3,0 сотовых или выше
  • iOS Safari на iOS 4 или выше
  • Windows Phone 7 или выше

Командная строка

  • cURL 7.18.1 или выше
  • wget 1.14 или выше (дистрибутивы, возможно, пластырь для поддержки SNI)

Без поддержки

  • Браузер BlackBerry
  • Internet Explorer (любая версия) в Windows XP

(Примечание. Некоторая информация для этого ответа была получена из Википедия.)


95
2017-08-14 23:05



Гораздо лучше :-) Надеюсь, это может в конечном итоге получить более высокий балл, чем тот, который в настоящее время принят, что, кроме последнего редактирования наверху, в большинстве случаев неверно. - Bruno
@Bruno Я, конечно, не буду жаловаться, если вы найдёте несколько сотен человек, чтобы повысить его. :) - Michael Hampton♦
В последнем браузере BlackBerry (10?) Используется последняя версия WebKit, поэтому очень вероятно, что он поддерживает SNI. - dave1010


Проблема:

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

Вот упрощенный пример такого рукопожатия:

tls handshake

Если это HTTP, а не HTTPS, первое, что отправил клиент, было бы примерно так:

GET /index.html HTTP/1.1
Host: example.com

Это сделало возможным несколько виртуальных хостов на одном IP-адресе, так как сервер точно знает, к какому домену клиент обращается, а именно example.com.

HTTPS отличается. Как я уже говорил, рукопожатие приходит прежде всего. Если вы посмотрите на третий шаг рукопожатия, показанный выше (сертификат), сервер должен представить сертификат клиенту как часть рукопожатия, но не имеет понятия, какое доменное имя клиент пытается получить. Единственный вариант, который имеет сервер - это отправлять один и тот же сертификат каждый раз, его сертификат по умолчанию.

Вы все равно можете настроить виртуальные хосты на своем веб-сервере, но сервер всегда будет отправлять один и тот же сертификат каждому клиенту. Если вы попытались разместить сайты example.com и example.org на своем сервере, сервер всегда будет отправлять сертификат на example.com, когда клиент запрашивает соединение HTTPS. Поэтому, когда клиент запрашивает example.org через установленное соединение HTTPS, это произойдет:

enter image description here

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

Решение:

Самый простой способ решить эту проблему - это указать клиенту сервер, к домену, к которому он хочет получить доступ. во время рукопожатия, Таким образом, сервер может обслуживать правильный сертификат.

Это именно то, что SNI, или указатель имени сервера.

С SNI клиент отправляет имя сервера, к которому он хочет получить доступ, как часть первого сообщения, шаг «Клиент Hello» в диаграмме рукопожатия выше.

Некоторые старые веб-браузеры не поддерживают SNI. Например, в Windows XP не является одной версией Internet Explorer который поддерживает SNI. При доступе к ресурсу через HTTPS на сервере, который использует виртуальные хосты SNI, вам будет предоставлен общий сертификат, который может привести к тому, что браузер отобразит предупреждение или ошибку.

enter image description here

Я упростил здесь все, чтобы просто объяснить принцип проблемы и решение. Если вы хотите получить более техническое объяснение, википедия страницы или RFC 6066 может служить хорошим отправным пунктом. Вы также можете найти список серверов и браузеров, поддерживающих SNI. википедия


36
2017-08-14 19:13





http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Клиентский браузер также должен поддерживать SNI. Вот некоторые браузеры, которые делают:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

16
2018-02-05 00:46





Расширение TLS для имени сервера (RFC6066) требуется для того, чтобы основанные на имени vhosts работали над HTTPS.

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


6
2017-08-14 19:10



В дополнение к ответу Falcon, IIS также требует особых изменений, чтобы заставить несколько сайтов IIS работать над одним и тем же IP-адресом. Вы должны вручную отредактировать файл конфигурации для сервера или использовать инструмент CLI для внесения изменений привязки, инструмент GUI не может этого сделать. В IIS это называется назначением сертификатов SSL для заголовков хостов. Некоторое время у Apache не было проблем. - Brent Pabst
Ах, хорошо, это немного очищает. Как узнать, поддерживает ли клиент (браузер) это? Например, если я хочу проверить MSIE6, как я могу проверить, что без установки виртуальной машины XP или так? - Luc
@Luc en.wikipedia.org/wiki/Server_Name_Indication#Support - cjc
@Falcon SNI не работает с IE на XP; который по-прежнему составляет почти четверть пользователей настольных компьютеров. Я бы не назвал это «широко реализованным», когда четверть потенциальных посетителей не работает. - Chris S
@MichaelHampton IE использует собственный склеп-стек Windows для SSL. XP не поддерживает SNI, поэтому любая версия IE, работающая под XP, тоже не работает. IE поддерживает только SNI в Vista и более новых ОС. - Chris S