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

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

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

Первая ступень ракеты-носителя Falcon 9 снова совершила жёсткую посадку на плавучую платформу: ступень опрокинулась после достаточно сильного удара о платформу. Но, вроде бы, дела обстоят лучше, чем в прошлый раз.

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-сертификатах (а в дальнейшем, очевидно, во всех типах сертификатов, используемых на веб-узлах), должны сделать её популярной и обязательной.

Сейчас корни китайского УЦ CNNIC не поддерживается браузерами (Chrome и Firefox) в полном объёме, это результат истории с выпуском “перехватывающих” промежуточных сертификатов. Google ставит в качестве условия возврата доверия CNNIC-у – полную поддержку Certificate Transparency (CT). Интересно, что если CNNIC такую поддержку реализует, то это будет первый УЦ, который реализовал CT в полном масштабе даже не потому, что есть RFC, а лишь под давлением разработчиков браузеров.

Ко Дню космонавтики – традиционное изображение ракеты. Советская почтовая марка из 1972 года:

Подробное описание уязвимости CVE-2015-1130 в Apple OS X и истории её обнаружения, с примерами кода. Уязвимость позволяет произвольному пользователю получить файл, исполняемый на локальной машине с правами root. Для эскалации привилегий используется системный API, в котором содержится ошибка. Пишут, что уязвимость существовала как минимум с 2011 года.

В домене .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), но это не проблема.