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

Небольшое дополнение к прошлой заметке по теме, рассказывающей о контроле доверия в DANE. Напомню, речь идёт о том, что DANE, в случае применения с самоподписанным сертификатом, основывается только на административной иерархии DNS. А там, во многих случаях, не тщательно проверяются данные администраторов доменов. (Тут нужно заметить, что есть и виды SSL-сертификатов, которые также выдаются без особых проверок – достаточно управлять почтой на домене, для которого вы заказали сертификат.)

Так вот, есть ещё одно важное отличие между DANE+TLS (SSL) и чисто TLS (SSL). В случае с DANE, для того чтобы воспользоваться предоставляемыми возможностями и мимикрировать под “безопасный сайт” злоумышленнику нужно зарегистрировать другой домен. (Взлом цепочки управления DNS тут не рассматриваем.) Да, домен может быть визуально похож на адрес атакуемого сайта, как в хрестоматийном примере yandex.ru и yanclex.ru, но это другой домен. В случае же с имеющейся инфраструктурой удостоверяющих центров, выдающих SSL-сертификаты, злоумышленник может получить сертификат для того же самого домена. Что, кстати, не исключает тем более беспроблемного получения сертификата для условного yanclex-а. То есть, благодаря особенностям DNS, отличие DANE принципиальное – нельзя зарегистрировать и разместить в глобальной DNS второй домен, точно совпадающий с атакуемым. А вот выпустить без ведома администратора домена SSL-сертификат для него – можно. Естественно, с существенными оговорками, но, опять же, без взлома цепочки доверия. Свежее доказательство – история с TURKTRUST.

Это преимущество DANE.

TURKTRUST – удостоверяющий центр (УЦ), выпустивший левые сертификаты промежуточных УЦ, – публикует некие технические подробности, объясняя, как такое произошло. Это самая правильная реакция.

Они, фактически, в мягких формулировках, признают, что один из сертификатов использовался клиентом в системе инспекции (корпоративного) трафика, для перехвата HTTPS. Этот момент и выплыл наружу, что, естественно, не планировалось. Конечно, не просто поверить, что подходящий для перехвата HTTPS сертификат, к тому же, использовавшийся для такого перехвата, был выпущен в результате настоящей, чисто технической, ошибки. С другой стороны, нельзя исключать, что такое применение сертификату нашёл довольный админ, внезапно заметивший, какое сокровище попало к нему в руки.

Google сообщает, что 24 декабря они при помощи Chrome обнаружили в Сети очередной “левый” сертификат для *.google.com (дополнение: и не только для *.google.com, но и для множества других адресов гугловских сервисов). Сертификат был выпущен “промежуточным” удостоверяющим центром (УЦ), действовавшем от имени TURKTRUST (это известный признанный УЦ, его корень наверняка встроен и в ваш бразер).

Занимательно объяснение TURKTRUST, которое приводят в блоге Google:

“TURKTRUST told us that based on our information, they discovered that, in August 2011, they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates.”

(TURKTRUST сообщили нам, что, на основании нашей информации, они обнаружили, что в августе 2011 года ошибочно выпустили два сертификата промежуточных УЦ для организаций, которые должны были вместо этого получить рядовые SSL-сертификаты.)

То есть, ключи УЦ, позволяющие выпустить неотличимый от настоящего сертификат для любого домена, болтались где-то в пространстве больше года. Сейчас их случайно заметили. Оказалось – типа, техническая ошибка. Ну, бывает. Прекрасно работает современная инфраструктура SSL, не правда ли?

В рассылке IETF напоминают, что сегодня – 30 лет с момента перехода ARPANET на TCP/IP с более древнего протокола, который назывался NCP (сейчас мало кто вообще о нём слышал). ARPANET – предвестник современной глобальной Сети – перевели на использование группы протоколов TCP/IP с 1 января 1983 года. Собственно, как ни крути, а историю Интернета в современном понимании можно отсчитывать только с этого момента, потому что привычный Интернет – это TCP/IP. В такой трактовке Интернету исполнилось сегодня 30 лет.

Процесс перехода описан в RFC 801, датированным ноябрём 1981 года. Интересно, что в современной Сети остались некоторые другие протоколы (“сервисы”), работавшие в ARPANET до перехода на TCP/IP. Это FTP и Telnet. Настоящие динозавры. Конечно, никакого Веба в те годы не существовало.

Буквально вот только что в корневой зоне DNS появилась DS-запись для ключа зоны .ru. То есть, теперь DNSSEC в .ru есть и работает.

На конференции ITU (МСЭ) готовят некоторую резолюцию, касающуюся взаимоотношения суверенных телекоммуникационных прав государств и Интернета, в котором с закреплением этих прав у многих государств мира есть, так сказать, определённые трудности. Скорее всего, резолюцию примут. Она, так или иначе, будет касаться распределения адресного пространства. Но вот каких-то действенных технических рычагов, способных перераспределить контроль над адресным пространством Интернета, от этого не появится. В общем, посмотрим. Результатов ждать не так долго.

(Занятно, что на этой Всемирной конференции по международной электросвязи уже приключилась заметная авария с доступом к Интернету. Традиция, однако.)

Update (16/12/12): нет, не приняли ничего конкретного в отношении Интернета; ICANN сохраняет статус.

В зоне .ru вчера появились записи DNSKEY, в которых опубликованы ключи KSK и ZSK для зоны, с соответствующей подписью. Следующий шаг – появление DS-записей (тоже с подписями) в корневой зоне DNS. Что, как обещают, должно случиться до конца года.

Опубликовано исследование распространения CMS в Рунете, включающее, кроме того, анализ использования современных веб-технологий (HTML5, различные DOCTYPE и др.). Выполнено аналитической группой RU-CENTER.

С большим отрывом побеждают Joomla! и WordPress, Drupal – третий. Там, по ссылке, опубликовано описание методики и ещё куча интересной статистики.

Координационный и технический центры российских национальных доменов готовятся к введению DNSSEC в .ru – это основной домен из трёх (su, рф, ru). Вот, пишут, что сгенерировали ключи и положили их на изолированный компьютер (air gap, да). Подписать .ru обещали до конца этого года. Так что можно, в принципе, готовить серверы и свои зоны. (Я dxdt.ru уже подписал; вот значение для DS – 12E833887648F73B80E06CC86252E025FFE5F75F.)

Существует технология DANE, позволяющая использовать DNSSEC для контроля достоверности SSL-сертификатов. Пока что, технология эта далека от практического внедрения, хоть и выглядит очень привлекательно. Существенный вклад в формирование этой привлекательности вносит тот факт, что DANE позволяет придать столь популярным “самоподписанным сертификатам” новый статус, привязав их к цепочке доверия DNS. Конечно, только если в домене уже работает DNSSEC.

У DANE, впрочем, есть некоторые особенности, – скорее, негативные, – которые связаны с тем, что для обеспечения управления доверием используется DNS. Причём, фактически, важную роль играет административная структура этой системы, а не чисто техническая.

Предположим, что кто-то желает перехватить соединение с веб-сайтом, работающим по HTTPS, не вызвав каких-то предупреждений в браузере и подозрений у пользователя. Предположим, что DANE выступает в качестве замены инфраструктуры SSL. Тогда, для незаметного перехвата, достаточно получить управление серверами имён, поддерживающими домен, в котором находится атакуемый сайт. Серверы можно взломать. Или просто изменить на свои. Существенный момент: потребуется перехватить и управление записями DNSSEC в зоне уровнем выше, либо заполучить секретный ключ, с помощью которого подписывается зона. При правильном сопровождении домена – сделать это непросто. Однако нельзя исключать, во-первых, взлома панели управления регистратора, а, во-вторых, того, что на каком-то этапе какой-то провайдер DNS может “посотрудничать” с “заинтересованными лицами”.

Дальнейшие шаги понятны: генерируется “самоподписанный” сертификат для атакуемого домена (сайта), вносятся записи DANE в доменную зону, и всё – готово: HTTPS-соединение качественно перехвачено.

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

Этот, только что описанный, момент, а также довольно интересное наблюдение, говорящие нам о том, что если удостоверяющие центры во многих случаях обязаны тщательно проверять клиентов, которым выдают сертификаты, а регистраторы доменов тщательную проверку могут не проводить (не проводят, естественно; иначе – рынок рухнет), являются основными аргументами против внедрения DANE. Но есть надежда, что технологию таки введут в обиход, несмотря на эти потенциальные проблемы. Проблемы можно задавить тщательной реализацией DANE в браузерах.

(Напомню, что в спецификации DANE учтены случаи использования SSL-сертификатов, выданных удостоверяющими центрами, которые могут входить в существующую “браузерную” инфраструктуру; а могут и не входить, да.)

График, отражающий отключение Интернета в Сирии:

Более подробная информация – на сайте Renesys.