Лучшее понимание альтернативных имен TLS / SSL?

До того, как появилась альтернативная тема Имя (SAN) расширение, сертификаты могут иметь только одно «общее имя». Это общее имя использовалось клиентом для проверки того, что служба, с которой они разговаривают, является службой, с которой, как они ожидали, будут разговаривать, а не вредоносной, поддельной или неправильно настроенной службой.

В частности, для веб-сайтов. , многим сайтам нравится иметь несколько возможных имен, которые клиенты могут использовать для подключения (www.example.com, example.com, example.net, www.example.co.uk, example.tv). Но получить сертификат на каждое возможное имя было обузой. Кроме того, более ранние версии протоколов SSL и TLS требовали, чтобы каждый сертификат размещался на уникальной комбинации IP / порта, что добавляло дополнительных затрат и усилий по настройке.

Расширение SAN позволяет использовать несколько дополнительных идентификаторов (а не только DNS-имена). связаны с одним сертификатом. Это огромная экономия времени и средств для решения обеих проблем, упомянутых выше. Один сайт с несколькими именами теперь может использовать один сертификат, содержащий все имена с одной комбинацией IP / порта на веб-сервере.

Сертификаты SAN также могут быть полезны даже для разных сайтов, находящихся за общим балансировщиком нагрузки или обратным прокси-сервером. который разрывает соединение TLS. Это обычное явление в сети доставки контента (CDN), например CloudFlare или Akamai . Вот почему вы можете найти сертификаты в дикой природе с множеством, казалось бы, несвязанных записей SAN.

Отвечая на другие ваши вопросы:

Все ли эти домены совместно используют сертификат?

Да

Есть ли есть ли риски безопасности (атаки MitM?) с использованием альтернативных имен?

Нет конкретных безопасности рисков при использовании сертификатов SAN. Они так же надежны, как и сертификаты, не относящиеся к SAN. Однако можно возразить, что у вас есть обычные риски, связанные с тем, что кладете «много яиц в одну корзину». Проблема с этим сертификатом затрагивает все сайты, которые его используют.

TL; DR: это Cloudflare

. Во-первых, обратите внимание, что сертификаты X.509 могут содержать два разных расширения: Subject Альтернативное имя (я) и альтернативное имя (имена) эмитента. . На практике никто не использует IssuerAltNames, и отчет SSLLabs, который вы скопировали, показывает (только) SubjectAltNames, которые сейчас используют практически все, а браузеры (совсем недавно) начали требовать .

Сервер, использующий этот сертификат, является часть сети CloudFlare. CloudFlare является (в первую очередь) так называемой «сетью доставки контента», что означает, что они запускают веб-серверы, которые изначально обрабатывают запросы WWW от браузеров и т. Д. Для лотов веб-сайтов / доменов, принадлежащих их клиентам. . Процитируем их FAQ:

Как работает Cloudflare?
Cloudflare защищает и ускоряет работу любого веб-сайта в Интернете. Когда ваш веб-сайт становится частью сообщества Cloudflare, его веб-трафик направляется через нашу интеллектуальную глобальную сеть. Мы автоматически оптимизируем доставку ваших веб-страниц, чтобы ваши посетители получали максимальную скорость загрузки страниц и лучшую производительность. Мы также блокируем угрозы и ограничиваем использование злоумышленниками ботов и поисковых роботов, которые тратят вашу пропускную способность и ресурсы сервера.

Согласно их домашней странице, в настоящее время они обрабатывают 6 миллионов «объектов» (предположительно доменов) в 115 центрах обработки данных по всему миру. Для этого они обрабатывают несколько доменов на каждом сервере (в противном случае им потребуется больше серверов, чем кто-либо может себе позволить), и сертификат по умолчанию отражает это, хотя они предлагают выделенные сертификаты за дополнительную плату .

Существует возможный риск при использовании общего сервера: если CloudFlare имеет ошибку или делает ошибку, это влияет на все сайты, обрабатываемые затронутыми серверами, и в некоторых случаях это было (см. Статью в википедии). Однако, поскольку их основная деятельность и постоянная работа связаны с этими серверами, серверы CloudFlare, вероятно, лучше настраиваются, контролируются и быстрее исправляются при возникновении проблемы, чем большинство (я предполагаю, что не менее 90%) исходных серверов работают. напрямую владельцами доменов.

Нет значительного дополнительного риска при использовании общего сертификата, поскольку любой, кто просматривает разрешения DNS для затронутых доменов, уже может увидеть, что они проходят через CloudFlare - и все достаточно новое программное обеспечение поддерживает SAN, поэтому очень немногие клиенты, у которых возникают проблемы с подключением к серверу с помощью сертификата SAN, вероятно, все равно будут вытеснены. (Не путайте это с тем, что несколько менее древнее программное обеспечение, такое как WindowsXP, ранние версии Android и Java6 (!), Не поддерживает указание имени сервера, также известное как SNI, родственную, но другую функцию TLS .)

Обратите внимание, что даже «внутренние» веб-серверы могут по-прежнему использовать довольно много записей SubjectAltName в случаях, когда одно предприятие владеет и использует несколько доменных имен, например:

• (без подстановочных знаков) поддомены, такие как www.bigcorp.com sales .bigcorp.com support.bigcorp.com или
• одинаковые или похожие имена в разных TLD, таких как www.bigcorp.co.uk, www.bigcorp.co.jp или
• , явно разные имена, например, www.bigpreviousname.com www. bigbrandslogan.com и т. д.