dxdt.blog: занимательный интернет-журнал

Хэш-функция SHA-1 уже несколько лет считается недостаточно стойкой для использования в подписях SSL-сертификатов. Сейчас идёт процесс вытеснения этой функции из действующих сертификатов, но пока что таких сертификатов много, они встречаются сплошь и рядом. Использование SHA-1 приводит к “неожиданным” эффектам в браузерах. Посмотрим на один из примеров – сайт nic.ru.

На сервере, где расположен nic.ru, установлен валидный сертификат с расширенной проверкой (EV). Однако если зайти на сайт при помощи браузера Chrome (42.0.2311.90 – актуальная на момент написания заметки версия), работающего в среде операционной системы Windows (версии 8.1, например), то в адресной строке браузера появляется предупреждение о том, что сайт использует устаревшие технологии безопасности. Выглядит это так:

Естественно, ожидается, что корректно установленный EV-сертификат приведёт к другому эффекту, отобразив “доверенную” адресную строку. Так происходит в браузере Internet Explorer 10, на той же тестовой машине:

А если воспользоваться браузером Mozilla Firefox, то эффект тоже положительный:

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

Посмотрим на набор сертификатов, возвращаемых сервером. Здесь есть три сертификата: серверный и два промежуточных; вот их свойства, указанные в полях Subject (s, предмет сертификации) и Issuer (i, удостоверяющая сторона):

0.
s:O=JSC ‘RU-CENTER’/OU=Project Department/CN=www.nic.ru
i:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4

1.
s:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4
i:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority

2.
s:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority
i:O=Equifax/OU=Equifax Secure Certificate Authority

(Имя nic.ru без www. указано в расширении SAN сертификата, так что адреса на скриншотах – корректны.)

Проблемным является сертификат под номером 2 (выпущенный для GeoTrust Primary Certification Authority), так как он использует SHA-1 в составе алгоритма генерации подписи. Согласно политике Google Chrome, если в цепочку сертификатов (исключая корень) входит хотя бы один, подписанный с использованием SHA-1, то в адресной строке выводится предупреждение. Посмотрим на цепочку:

Всё сходится – промежуточный сертификат с SHA-1 входит в цепочку сразу после корня. (Обратите, кстати, внимание на то, что корень обозначен как GeoTrust, хотя сам корневой сертификат содержит название Equifax, в чём можно убедиться, если посмотреть внутрь его полей. Это следы маркетинга: бизнес по продаже цифровых сертификатов Equifax был продан компании, оказывающей эти услуги под брендом GeoTrust.) IE использует тот же набор корней, однако политика этого браузера позволяет даже EV-сертификатам быть подписанным по цепочке, включающей SHA-1, поэтому здесь всё хорошо.

А вот Firefox использует собственный набор корней, поэтому цепочка валидации тут иная:

Firefox содержит доверенный корень, обозначенный как GeoTrust Primary Certification Authority, от которого подписан промежуточный сертификат GeoTrust EV SSL CA – G4. То есть, те же сертификаты уже выстраиваются в цепочку, которая не содержит SHA-1, поэтому данная ситуация не может вызвать предупреждения, даже если бы такое предупреждение поддерживалось Firefox. Аналогично устроен и Google Chrome под Linux – там тоже встроен корень, позволяющий избежать использования промежуточного сертификата с SHA-1.

Выше я упомянул о том, что присутствие SHA-1 не учитывается для корневых сертификатов (встроенных в браузеры). Почему? Причина в том, что корневые сертификаты самоподписанные (по определению), а браузер доверяет не подписи, а открытому ключу, связанному с корневым сертификатом, и имени удостоверяющего центра, которое указано в сертификате. Раз подпись не играет ключевой роли, то и использованием SHA-1 в корневом сертификате можно пренебречь: оно никак не влияет на уровень доверия.

Что нужно делать веб-сайтам? Нужно перевыпускать сертификат в цепочке, которая не использует SHA-1.

Сейчас из некоторых российских сетей недоступны NS-ы GoDaddy, например, вот эти: ns20.domaincontrol.com, ns19.domaincontrol.com. На данные серверы имён делегировано много доменов, соответственно, как только завершится время кэширования, сайты под такими доменами станут недоступны для пользователей российских провайдеров. Из США и Европы – пока что всё работает, серверы “Премиум-DNS” GoDaddy – тоже доступны, пока что. Но, возможно, это авария, ну или ошибка в настройках маршрутизации (как обычно бывает).

Update (17/04/15): исправили; проблема наблюдалась для нескольких групп серверов, и не только для России.

US-CERT распространил новое предупреждение об угрозе: “трансфер зоны DNS может раскрыть информацию о домене“. Это довольно странно, потому что известно очень много лет, соответственно – какая новая угроза? (В предупреждении, впрочем, сказано, что причина в большом распространении серверов, разрешающих трансфер зроны для всех желающих.)

Запросы AXFR (Asynchronous Transfer Full Range) – трансфер зоны – позволяют получить с сервера имён полный список записей в зоне DNS, то есть, фактически, увидеть все настройки адресации домена. Эти запросы используются для передачи сведений между разными авторитативными серверами, поддерживающими зону, а также в других случаях. Разумное толкование подсказывает, что все данные, публикуемые в глобальной DNS, должны являться публичными, по определению. Те не менее, доступ на трансфер зоны обычно ограничивают некоторыми доверенными серверами, чтобы не всякий мог скачать всю зону одним запросом, а только те узлы, которым это нужно. Так делается много лет.

Вообще, споры о том, нужно ли считать угрозой возможность получения полного (или близкого к полному) списка записей в той или иной доменной зоне – идут уже сильно дольше десяти лет. Например, этот момент повлиял на технологию DNSSEC. Для того, чтобы подтвердить, что записи для некоторого имени не существует, в DNSSEC нужно передавать в ответ на запрос указание на “ближайшую” существующую запись (на имя записи). Изначально разработчики DNSSEC пошли по “открытому пути” и предложили решение с записями NSEC, которые, в ответ на запрос о несуществующем имени, просто включают одно из имён в зоне, в открытом виде. Естественно, это позволяет быстро перебрать все записи и получить полный список имён, реконструировав зону. Защитники “безопасности через сокрытие” выставили кучу возражений, в результате появилось расширение NSEC3, где ответы содержат не сами имена, а значения хеш-функций, что делает перебор вычислительно трудным.

Так вот теперь, похоже, нужно ждать свежего “открытия” “угрозы” раскрытия списка имён доменной зоны через NSEC в технологии DNSSEC. Хотя, DNSSEC пока что не имеет должного распространения.

Существуют EV-сертификаты для TLS. Это сертификаты с расширенной проверкой организации, для домена которой выпускается сертификат. Технически, они такие же, как и обычные, но красят адресную строку в некоторых браузерах в зелёный цвет. Теперь для EV-сертификатов нужна поддержка Certificate Transparency (согласно рекомендациям разработчиков браузеров; сейчас требование актуально только для линейки Google Chrome). Посмотрим, как это выглядит на практике, для пользователя браузера Chrome (англоязычный интерфейс). Для примера я возьму сайт интернет-банка “Альфа-банка”. Сведения о статусе аудита Certificate Transparency (CT) отображаются в выпадающем окошке, по клику на название организации в адресной строке браузера:

Наличие строки Transparency information говорит о том, что в сертификате содержатся записи из логов CT. По клику открывается окно с дополнительной информацией:

О чём данные из этого окна говорят типичному пользователю? Да, к сожалению, ни о чём. Разобраться в них сложнее, чем в структуре сертификата, потому что для понимания требуется знание того, как работает технология CT. Ну, разве что, можно обратить внимание на то, что указана дата, когда сертификат был внесён в лог (в нашем случае эта дата совпадает с датой начала действия сертификата), да и на то, что наличие сертификата в логе подтверждено подписями (статус Verified), а это означает, что данный сертификат, скорее всего, был действительно выпущен для указанного сервера, согласно соответствующим процедурам.

Сведения о включении сертифката в лог CT содержатся в самом сертификате, для этого в расширения X.509 внесено специальное поле:

Пока что технология CT не очень распространена, но поддержка ведущими браузерами и требование по наличию этой технологии в дорогих EV-сертификатах (а в дальнейшем, очевидно, во всех типах сертификатов, используемых на веб-узлах), должны сделать её популярной и обязательной.

В домене .ORG доступны однобуквенные имена. Отличный пример: X.ORG (там есть соответствующий сайт, конечно же). Это довольно дорогие доменные имена. Похоже, что в апреле домен i.org приобрёл некоторую связь с Facebook – как минимум, на это указывают записи Whois (почему-то, с минусом, да):

$ whois i.org | grep ‘Organization’
Registrant Organization:-Facebook
Admin Organization:-Facebook
Tech Organization:-Facebook

Домен делегирован на серверы a.ns.facebook.com и b.ns.facebook.com, которые, впрочем, на запросы об этом имени не отвечают (просто молчат в ответ по UDP, а по TCP – эти сервера имён вообще разговаривать сразу отказываются).

К вопросу доступности современных веб-сайтов, использующих HTTPS, для поисковых роботов. Несколько дней назад мне подсказали, что “Яндекс.Картинки” не индексируют файлы по HTTPS, требуя доступа по HTTP. Поверхностное исследование выдачи поисковика подтвердило, что это, похоже, так и есть (более того, в документации прямо сказано, что требуется HTTP для URL-ов картинок). Я воспользовался штатной формой обратной связи и написал в “Яндекс” следующее письмо:

Здравствуйте!

На странице http://help.yandex.ru/images/indexing.xml сказано, что поиск Яндекса по картинкам не поддерживает HTTPS. Точнее, для индексации файла картинки требуется, чтобы файл было доступен по HTTP. Сейчас веб-сайты массово переходят на защищённый протокол (более того, TLS является основным рекомендованным транспортом в HTTP/2). В идеале, весь контент современного веб-сайта должен передаваться веб-сервером по HTTPS, это касается и картинок, потому что “вынос” изображений в открытый протокол HTTP несёт с собой риски возникновения проблем с безопасным доступном к сайту в целом, так как предоставляет возможности для “деградации” протокола при доступе к определённым URL.

Таким образом, сейчас изображения с сайтов, поддерживающих только безопасный протокол HTTPS, не попадут в индекс поиска по картинкам. Планируется ли в ближайшее время исправить ситуацию, добавив поддержку для сайтов, доступных только по HTTPS?

Спустя три дня получил лаконичный ответ от Платона Щукина:

Здравствуйте, Александр!

Эта ситуация уже исправлена. Картинки индексируются по https.

Неплохо, если так, хотя и противоречит описанию на сайте. Что ж, ждём обновления индекса.

После обновления “Яндекс.Карт” проблема с обработкой корневого домена в URL вернулась. Правда, теперь они показывают “ошибку 503” вместо некоторого “сервисного” XML-документа: https://maps.yandex.ru./

Конечно же, указание корневого домена в URL и близко не является какой-то распространённой практикой. О существовании этой “крайней точки” вообще знают только квалифицированные специалисты, а пользователи – вообще не догадываются обо всех этих крайне важных для работы Сети заморочках. Более того, не раз приходилось видеть, как про точку забывают даже те самые специалисты, хотя и работают с DNS, где важнее точки – разве что её отсутствие. (Забывчивость в DNS приводит к более плачевным, по сравнению с веб-сервисами, последствиям: целые густо населённые доменные зоны исчезают из Интернета, а иногда их трафик полностью перенаправляется в адрес ни о чём не подозревающего одинокого сервера.) Тем не менее, то, что пользователи браузеров не вводят адреса с корневым доменом, не означает, что огромный сервис, вроде “Яндекс.Карт”, может неверно обрабатывать URLы.

Технология HSTS (HTTP Strict Transport Security) позволяет принудительно переводить браузер в режим HTTPS для некоторых URL, это требуется для того, чтобы предотвратить активные атаки, основанные на замене протокола. Однако на базе HSTS придумали делать “суперкуки” – то есть, идентифицировать браузер, даже если он работает в “анонимном” режиме, не отправляет куки-файлы. Технология довольно занимательная: используется несколько адресов сайтов, с разным состоянием HSTS, это состояние (HTTP/HTTPS) соответствует одному биту идентификатора; javascript-ом состояния битов считываются с набора сайтов и собираются в число, идентифицирующее браузер. Конечно, требуется несколько десятков адресов (например, 32), но это не проблема.

Китайский удостоверяющий центр CNNIC, признаваемый всеми основными браузерами, поучаствовал своими ключами в выпуске промежуточного сертификата, который использовался в прозрачно перехватывающем трафик SSL-прокси. Об этом, конечно, стало быстро известно в Google (потому что браузер Chrome устроен достаточно добротно). Объяснения от CNNIC сводятся к тому, что, дескать, это всё была тестовая среда, а сертификаты утекли наружу случайно. Итог пока такой: корень CNNIC таки изымают из продуктов Google:

“As a result of a joint investigation of the events surrounding this incident by Google and CNNIC, we have decided that the CNNIC Root and EV CAs will no longer be recognized in Google products.” (В результате совместного расследования событий, связанных с данным инцидентом, мы приняли решение что CNNIC Root и EV УЦ больше не признаются продуктами Google.)

Это весьма резкое решение, но, собственно, такого варианта следовало ожидать. Mozilla пока думает, но в том же самом направлении. А для повторного включения корней CNNIC в браузеры планируют потребовать от УЦ поддержки Certificate Transparency.

В CNNNIC уже ответили, в том ключе, что шаг Google – неприемлем, требуют задуматься о правах пользователей.

Ссылка по теме: перехват HTTPS.

Update, 04/04/15: Mozilla подключилась – сертификаты, впущенные от корней CNNIC после 1 апреля 2015, не признаются. Таким образом, CNNIC, как коммерческий УЦ, теряет всякий смысл. Интересно, как прореагируют в Китае?

Google некоторое время назад зарегистрировал собственный домен верхнего уровня. Вот как они его используют: https://com.google. Весьма занятный вариант, да:

(Для полноты картины, конечно, нужно было регистрировать elgoog. Но, вероятно, просто забыли.)

Если набрать в адресной строке браузера адрес сервиса “Яндекс.Карты” с указанием корневого домена в URL – вот так: maps.yandex.ru. (с точкой после ru), – то вместо заглавной страницы сервиса можно наблюдать некий XML-документ, с разными внутренними комментариями и даже с указанием на ошибку, приведшую к этим плачевным результатам:

"Caught exception 'bad param: domain='maps.yandex.ru.'' in xscript::js::javascriptDomain".

Естественно, URL с прямым указанием корневого домена – вполне себе корректный.

Update (19/03/2015): дефект исправили.