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

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-серификатов в браузерах работают очень плохо, фактически – не работают, за некоторыми исключениями. Тем не менее, инфраструктура УЦ – один из очевидных рычагов, полностью аналогичный отзыву регистраций доменов.

Из имён .ru, корректно подписанных DNSSEC, для которых в DNS указаны записи TLSA (это технология DANE, дополняющая инфраструктуру SSL/TLS) – мне удалось найти только пять, вот они:

dxdt.ru
feuerplatz.ru
lexeyko.ru
megaid.ru
ojab.ru

Это из примерно 4,5 млн делегированных доменов. Мягко говоря, не слишком много.

На сайте Алекса Экслера читаем, что при работе с почтой (предоставляемой в домене exler.ru), теперь есть HTTPS, но нужно игнорировать предупреждение безопасности браузера:

Почта на Exler.ru теперь работает по HTTPS-протоколу с самоподписанным сертификатом. Системы безопасности в браузерах на самоподписаный сертификат будут ругаться – предупреждаю. Поэтому надо адрес mail.exler.ru занести в исключения (доверенные сертификаты) – тогда ругаться не будет.

(Сертификат там, кстати, отдаётся не самоподписанный, но это детали.)

Именно так приучают массового пользователя к тому, чтобы он, фактически, игнорировал HTTPS, убивая этот протокол. Дело в том, что призыв игнорировать предупреждения и добавлять исключения, делает HTTPS близким к открытому HTTP, в плане перехвата трафика. Потому что в XXI веке настроить SSL-прокси не так уж и сложно. Естественно, главное отличие, в смысле перехвата, остаётся: для чтения HTTP достаточно пассивного “снифера”, HTTPS потребует активной подмены узлов. Но приучать пользователей давить кнопку “Всё равно продолжить” (название условное) – это совсем нехорошо. (Признаваемый браузерами сертификат стоит не так дорого, можно ещё найти бесплатные, а уж для exler.ru, думаю, кто-нибудь просто подарил бы сертификат.)

На сайте Spiegel Online опубликован (PDF) занятный документ британского Центра правительственной связи (GCHQ – это спецслужба, занимающаяся, в том числе, радиоэлектронной разведкой). Документ, – конечно, полученный от Сноудена, – описывает технологию, которую рекомендуют применять для деанонимизации пользователей сети TOR. Технология, впрочем, известная, основанная на корреляции параметров трафика на входном и выходном узлах сети. Конкретно – используются временные параметры.

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

Собственно, методика известная (я, например, писал о ней в осеннем выпуске журнала “Доменные имена“), применяемая на практике, и не только в Великобритании, что подтверждает новая публикация “секретных документов” (датированных, кстати, 2011 годом). Более продвинутый вариант этой технологии деанонимизации TOR использует для построения сигнатур дополнительные параметры записываемого трафика. Между прочим, деанонимизацию можно проводить постфактум, используя ранее записанные сигнатуры. Весь трафик сохранять не требуется: как обычно, само использование TOR автоматически поднимает нужные флаги, выделяя интересующий поток из общего массива данных, идущих через узел мониторинга.

Ещё несколько лет назад сайт, доступный только по HTTPS, мог оказаться вне зоны действия различных поисковых роботов, которые по HTTPS не умели страницы извлекать. Сейчас это не так. Я посмотрел в логи веб-сервера dxdt.ru и выбрал (произвольно) записи от нескольких ботов, чтобы определить, какие протоколы и шифронаборы они используют. Вот результат:

Googlebot/2.1 – “TLSv1 ECDHE-RSA-AES256-SHA”
bingbot/2.0 – “TLSv1 ECDHE-RSA-AES256-SHA”
YandexBlogs/0.99 – “TLSv1 DHE-RSA-AES256-SHA”
YandexBot/3.0 – “TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384”
Mail.RU_Bot/2.0 – “TLSv1 DHE-RSA-AES256-SHA”
SputnikBot/2.3 – “TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384”
YandexImageResizer/2.0 – “TLSv1 DHE-RSA-AES256-SHA”
sukibot_heritrix/3.1.1 – “TLSv1 ECDHE-RSA-AES256-SHA”
R6_CommentReader – “TLSv1 ECDHE-RSA-AES128-SHA”
rogerbot/1.0 – “TLSv1.1 ECDHE-RSA-AES256-SHA”
linkdexbot/2.0 – “TLSv1.2 ECDHE-RSA-AES128-SHA”
AhrefsBot/5.0 – “TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384”
MJ12bot/v1.4.5 – “TLSv1 ECDHE-RSA-AES256-SHA”
DotBot/1.1 – “TLSv1 DHE-RSA-AES256-SHA”

То есть, никаких проблем с обходом сайтов по HTTPS у ключевых для Рунета ботов – нет. Формально, из крупных ботов, “Яндекс” – самый прогрессивный, в смысле поддержки протоколов: тут мы видим TLSv1.2 и AES в режиме GCM (что, собственно, ожидаемо). Не подкачал даже SputnikBot – тут тоже все суперсовременно. Естественно, в случае с ботами, используемые шифронаборы мало на что влияют, да и вряд ли могут рассматриваться как определяющий показатель, особенно в современной структуре Веба. Но зато можно сказать, что работающие по HTTPS сайты, даже если они используют современные настройки TLS, вполне себе доступны для индексации самыми значимыми поисковыми машинами. Это означает, что можно смело переходить на HTTPS, не опасаясь, что боты не доберутся до контента.

Поделюсь настройками TLS на веб-сервере dxdt.ru. Я использую связку Apache+mod_ssl (стандартное решение). Важнейшие параметры – это используемые протоколы, “шифронаборы” (Cipher Suites – часто переводят как “наборы шифров”), а также их приоритет. Например, сейчас не рекомендуется использовать SSLv3 (и более ранние версии, которые, конечно, экзотика, но всё ещё встречаются в “живой природе”). Соответственно, в ssl.conf (файл конфигурации mod_ssl) для хоста dxdt.ru указаны следующие строки:

SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite “EECDH+AESGCM EDH+AESGCM EECDH+AES EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4”

Первая директива (SSLProtocol) разрешает только TLS (в трёх версиях, как несложно догадаться). Протоколы семейства SSL – не поддерживаем. Вторая директива (SSLHonorCipherOrder) указывает, что mod_ssl должен использовать приоритеты наборов шифров, заданные сервером (а не клиентом, то есть браузеру не удастся навязать свои предпочтения).

Директива SSLCipherSuite – это самое сложное место в настройках. Она определяет допустимые криптографические наборы (“шифронаборы”: алгоритмы обмена ключами и аутентификации, шифр, режим шифрования, алгоритм дайджеста). Условные имена наборов разделены пробелами. Конкретный набор согласуется клиентом и сервером во время установления соединения. Если договориться о подходящем наборе не удалось – TLS-соединение не устанавливается (именно это и происходит в случае IE8 под Windows XP).

В mod_ssl используются сокращённые имена для обозначения групп шифронаборов. Например: EECDH+AESGCM означает, что для генерации сеансового ключа будет использоваться алгоритм Ephemeral elliptic-curve Diffie-Hellman (разновидность алгоритма Диффи-Хеллмана на эллиптических кривых), а в роли алгоритма шифрования выступит AES в режиме GCM (Galois/Counter Mode – Режим счётчика с “аутентификацией Галуа”: один из современных “продвинутых” режимов блочных шифров, обеспечивающий, в том числе, аутентификацию данных; Галуа там возникает потому, что алгоритм аутентификации работает в конечном поле).

Сайт dxdt.ru использует серверный сертификат с ключом RSA; соответственно, аутентификацию сеансовых ключей можно проводить только при помощи криптосистемы RSA. Это некоторым образом экономит нам пространство в конфигурационной строке mod_ssl: вовсе не обязательно вписывать туда подробные указания вроде EECDH+ECDSA+AESGCM, как нередко рекомендуют, – DSA всё равно не поддерживается.

Несложно догадаться, что подстроки в SSLCipherSuite, начинающиеся с ‘!’, обозначают запрет на использование определённых криптосистем или криптографических примитивов. Всегда полезно прямо запретить заведомо неподходящие алгоритмы. Отмечу, что, в соответствии с современными традициями, запрещён RC4 (хотя он всё равно не предлагался бы сервером с указанными шифронаборами – не подходит).

Update (23/12/2014): в комментариях подсказали изящный вариант, с отключением всего ненужного одной директивой -ALL в SSLCipherSuite; такой вариант требует более точного описания шифронаборов, но зато он лаконичен:

SSLCipherSuite “-ALL:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES”

(Обратите внимание, что пробелы заменены на двоеточия.)

В HTTP-ответ добавлено поле HSTS (HTTP Strict Transport Security – требование “принудительной безопасности” для HTTP):

Header add Strict-Transport-Security “max-age=15552000”

Данное поле означает, что, грубо говоря, браузер должен запомнить, что к данному сайту доступ необходимо осуществлять только по HTTPS, в течение времени, указанного в параметре max-age поля HSTS. Это позволяет защититься от множества атак, основанных на подмене протокола HTTPS на HTTP.

Вот. Так работает TLS на dxdt.ru.

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

Неясно, как так могло получиться, но атаковавшим ICANN удалось получить администраторский доступ к некоторым сервисам. Это удивительно потому, что авторизация в системах подобного уровня должна бы быть защищена от простого перехвата почты сотрудников. Хотя, конечно, никто не застрахован от ошибок. В итоге, из сервиса Centralized Zone Data System – это полезный инструмент, позволяющий получать файлы зон доменов New gTLD, – утекли контактные данные пользователей, а также пароли, но в хэшированном виде.

(Кстати, самое громкое дело было бы, если бы у ICANN, а точнее – у IANA и VeriSign, утянули бы секретный корневой ключ KSK от DNSSEC. Понятно, что, в текущей ситуации с поддержкой DNSSEC, катастрофы бы не случилось, но случай был бы весьма показательный. Дело в том, что до сих пор не разработана процедура ротации корневого ключа KSK, так что DNSSEC, разве что, оставалось бы просто выключить.)