Трудно поверить, но TLS Server Name Indication (SNI) существует уже тринадцать лет. В наше время это динозавр, но, как ни странно, мало используемый; хотя ситуация наконец-то меняется, и именно в этом блоге мы рассмотрим, как передовые балансировщики нагрузки edgeNEXUS могут поддерживать эту функцию. SNI решает одну из самых больших проблем, с которыми многие сталкиваются при работе с SSL/TLS/HTTPS: необходимость выделять драгоценный IP-адрес для каждого домена или поддомена, который необходимо защитить. Это необходимо, поскольку SSL/TLS защищает соединение до того, как мы сможем проверить начальный HTTP-запрос клиента, который содержит эти драгоценные данные о доменном имени.
Единственный способ быть уверенным в том, что мы предоставляем правильный сертификат, — это обслуживать только один сертификат на один IP-адрес и использовать DNS для обеспечения того, чтобы запросы к определенному доменному имени направлялись на IP-адрес узла, обслуживающего правильный сертификат для этого домена. В частном предприятии мы могли бы использовать тот же IP-адрес, но другой порт, но тогда мы обязаны убедиться, что все знают, что нужно использовать нестандартный порт. Это не совсем подходящий вариант, если речь идет о публичных службах, доступных через Интернет.
Мы могли бы использовать сертификаты wildcard, которые защищают все возможные поддомены (например, *.jetnexus.co.uk), но они никому не нравятся, и меньше всего — специалистам по безопасности. Что бы Вы ни думали о “НЕТ!” — мужчинах и женщинах из мира информационной безопасности, — они, вероятно, правы. Трудно доверять чему-то, что по своей сути представляет буквально все или все в пределах домена. Сколько устройств хранят и сколько сотрудников имеют доступ к используемому сертификату и ключу?
Сертификаты альтернативных имен серверов (SAN) тоже всегда были доступны, но они требуют знания каждого конкретного домена, который необходимо защитить, на момент их создания. Любое удаление или добавление доменного имени требует повторной генерации сертификата и обновления всех соответствующих хостов.
Это все более жесткий выбор, с которым мы все сталкиваемся снова и снова (наши пользователи и клиенты тоже): сжечь IP-адрес или принять компромисс (во всех смыслах). Все более трудный, потому что IP-адреса — это ограниченный ресурс, который с каждым днем становится все менее доступным и все более ценным. К счастью для нас, у этой давней проблемы уже много лет есть решение. Оно дает нам лучшее из всех миров, но до недавнего времени не имело большого влияния.
SNI предоставляет клиенту способ указать серверу (в нашем случае jetNEXUS) доменное имя, с которым он устанавливает соединение. Это делается путем заполнения поля расширения в первом TLS-пакете клиента (приветствие) именем домена. Оно отправляется “в открытом виде”, поэтому его можно прочитать до того, как сервер отправит свой сертификат SSL/TLS. Это дает серверу возможность отправить ожидаемый сертификат (при условии, что он у него есть) из того количества, которое ему было предоставлено.
Таким образом, один виртуальный сервис (и IP-адрес) может быть настроен на столько SSL-сертификатов для стольких доменных имен, сколько Вы хотите, чтобы он обслуживал. Каждый из них может иметь выделенный и действительный SSL-сертификат, корректно и безошибочно предоставленный на основе данных, предоставленных клиентом. Обслуживайте www.jetnexus.com и www.loadbalance.co.uk на одном IP-адресе и предоставляйте действительные сертификаты для обоих; никаких компромиссов, никакой суеты и никаких потерь IP-адресов.
Кроме того, Вы можете изменить список доменов, поддерживаемых виртуальной службой, когда захотите, сделав несколько щелчков мышью в графическом интерфейсе. Добавьте или удалите сертификаты, чтобы добавить или удалить домены, поддерживаемые Виртуальной службой. Только не забудьте одновременно обновить DNS. Хотите использовать разные реальные серверы для одного или двух дорогостоящих доменов — нет проблем, быстрое правило flightPATH — дело нескольких минут. То же самое касается сжатия HTTP, переписывания URL и всего остального, что Вам нужно. Единая виртуальная служба и IP-адрес для нескольких доменов очень желательны, но они не должны ограничивать уникальную обработку, которую Вы можете захотеть применить к трафику для разных доменов.
Я слышу Вас: “В чем подвох?”. Ну, раньше она точно была, и именно по этой причине SNI существует уже так долго, но только сейчас появляется в балансировке нагрузки и других продуктах. Эта причина? Поддержка клиентов. Долговечность невероятно популярной комбинации Windows XP и IE6, которая не поддерживает SNI, не позволила большинству использовать ее. Никто не хочет потенциально отсекать 10-20% своей аудитории.
Однако сегодня все гораздо проще: срок поддержки Windows XP давно истек, IE6 используется менее чем в 1% случаев в дикой сети, а бесплатное обновление до Windows 10 быстро распространяется и принимается. Наконец-то мы можем быть уверены, что внедрение SNI не окажет влияния на наших клиентов и наш бизнес. IE 7 и выше (на Vista или более поздних версиях) и почти все версии Chrome, Firefox и Safari, кроме самых древних, поддерживают SNI. Если Вы хотите проверить и убедиться в том, что у Вас есть конкретная пользовательская база, для этого тоже есть правило flightPATH.
Что касается вопроса безопасности, то давайте проясним ситуацию: клиент предоставляет информацию в виде обычного текста. Эту информацию можно перехватить по проводам. Перед подключением клиент также делает DNS-запрос открытым текстом. Мы не можем это контролировать, поэтому раскрытие этой информации во второй раз позже не считается риском. Возможно, Вы захотите проверить, что доменное имя SNI совпадает с именем, найденным в заголовке HTTP Host, с помощью правила flightPATH, или, возможно, Вам все равно, ведь все люди разные. Не наводит ли это на мысль о проблеме безопасности? В любом случае, клиент подключен, и соединение безопасно. Если Вы не применяете политику безопасности на основе доменного имени (а этого делать не следует), то все в порядке.
Если Вам действительно нужна более подробная информация, посмотрите оригинальный RFC3546(раздел 3.1), более поздний RFC6066(раздел 3) и, если Вы считаете, что им можно доверять: Указание имени сервера на Wikipedi. Если Вам нужна безопасность на уровне приложений, edgeNEXUS WAF основан на ведущей в отрасли технологии усиленного межсетевого экрана приложений. Доступный через магазин приложений edgeNEXUS App Store и использующий технологию контейнеров нового поколения, брандмауэр приложений edgeNEXUS обеспечивает комплексную защиту, соответствующую требованиям соответствия PCI-DSS и OWASP. Как уже говорилось в предыдущих статьях блога, flightPATH — это динамическая система правил на основе событий, разработанная компанией edgeNEXUS для интеллектуального управления и маршрутизации сбалансированного по нагрузке IP-, HTTP- и HTTPS-трафика. Чтобы узнать больше об управлении трафиком flightPATH, пожалуйста, нажмите здесь, а чтобы узнать, как использовать все преимущества доступных правил, пожалуйста, обратитесь к Руководству пользователя edgeNEXUS.
Один виртуальный сервис (и IP-адрес) может быть настроен на столько SSL-сертификатов для стольких доменных имен, сколько Вы хотите, чтобы он обслуживал. Каждый из них может иметь выделенный и действительный SSL-сертификат, корректно и безошибочно предоставленный на основе данных, предоставленных клиентом.
