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

Существуют 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): дефект исправили.

Очередная история, отлично иллюстрирующая положение дел с безопасностью пользователей Сети: Lenovo исталлировали на ноутбуки дополнительное ПО Superfish (какое говорящее название!), которое подменяло серверные сертификаты веб-сайтов. Для чего подменяло? Конечно же для того, чтобы подставлять рекламу. Вот так.

Addon: поясню технические моменты – к сожалению, со стороны веб-сервера сделать здесь практически ничего нельзя; ни привязка ключей (Certificate Key Pinning), ни какой-нибудь DANE, ни другие методы (за исключением особо экзотических) – не помогают в случае, если вредоносное ПО установлено непосредственно внутри браузера и операционной системы. TLS помогает от атак на пути между сервером и клиентским компьютером, но не более того. Сходная проблема, кстати, существует и для антивирусных программ, подменяющих сертификаты и перехватывающих TLS непосредственно на пользовательском компьютере.

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

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

Кстати, многие государственные сайты в Рунете, а также сайты банков, используют HTTPS (это правильно). Соответствующие SSL-сертификаты нередко выпущены штатовскими удостоверяющими центрами (УЦ). Отзыв такого сертификата, в рамках “исполнения санкций”, приводит к тому, что у пользователей возникают проблемы при работе с сайтом: не то чтобы сайт оказался недоступен, но предупреждение системы безопасности браузера – появится (тем самым ценность HTTPS уничтожается). Конечно, механизмы отзыва SSL-серификатов в браузерах работают очень плохо, фактически – не работают, за некоторыми исключениями. Тем не менее, инфраструктура УЦ – один из очевидных рычагов, полностью аналогичный отзыву регистраций доменов.