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

Очередная история, отлично иллюстрирующая положение дел с безопасностью пользователей Сети: 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, разве что, оставалось бы просто выключить.)

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

Одна из хитростей состоит в том, что если в родительской (делегирующей) доменной зоне присутствует DS-запись для дочерней (делегируемой) зоны, и родительская зона безопасна (то есть, подписана DNSSEC), то это означает, что дочерняя зона тоже должна быть безопасной. То есть, валидирующий резолвер ожидает, что дочерняя зона содержит, во-первых, подходящие к DS ключи, нужные для проверки подписей, во-вторых – сами подписи на ответах об адресации внутри зоны. Соответственно, если DS-запись присутствует, а дочерняя зона не подписана, валидирующий резолвер будет возвращать сообщение об ошибке. Это совершенно правильное поведение, потому что иначе смысла в DNSSEC нет: подделать ответы без подписей не составляет труда; если резолвер не имеет возможности отличить подписанную зону от неподписанной по наличию DS-записи в доверенной (безопасной) зоне, то подписи можно вообще не проверять.

Другой важный момент: если авторитативный сервер родительской (делегирующей) зоны, подписанной DNSSEC, отвечает на рекурсивный запрос списком NS-ов и DS-записью, то подпись ставится только на значение DS. Казалось бы, нужно подписать и список NS-ов – как иначе узнать, что они правильные? Но если у нас есть доверенная DS-запись, то нет разницы, с каких серверов мы получим дополнительную информацию: главное, чтобы совпал ключ и его отпечаток в DS, а также сошлись значения подписей. Тут работает основной принцип DNSSEC: если данные об адресации аутентифицированы, то не имеет значения, из какого источника они получены.

Если для дочерней (делегируемой) зоны DS-записи нет, ответ авторитативного сервера содержит подписанное подтверждение тому, что эта запись действительно отсутствует. Это позволяет валидирующему резолверу убедиться в том, что дочерняя зона не является безопасной и записи из неё можно использовать, но только как неаутентифицированные (если такое допускается).

Google Public DNS для зон, имеющих DS-запись, но не подписанных, возвращает ошибку (SERVFAIL), вне зависимости от того, какова природа этих DS-записей. Другие валидирующие резолверы ведут себя иначе. Например BIND, обнаружив неизвестный алгоритм генерации DS, считает, что DS-записи в родительской зоне вовсе нет (что не совсем корректно, но с практической точки зрения оправдано, и, конечно, соответствует рекомендациям RFC). Пример такого поведения можно наблюдать для зоны dotsu.su – здесь в .su специально указаны DS-записи с неизвестным алгоритмом (9).

(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в DNSSEC. Думаю, что описание заслуживает публикации на dxdt.ru – потому что до сих пор нередко путают ключи, зоны, цепочки делегирования и прочие важные моменты.)

Посмотрим на то, как используются ключи DNSSEC, взяв для примера зону .org. Предположим, что мы справшиваем SOA-запись для .org у корневого сервера. Тогда, вместе с адресами NS-ов домена org, если последний делегирован безопасно, то есть, с DNSSEC, мы получим от корневого сервера DS-запись (или несколько – сейчас, например, их для .org две) и RRSIG-запись для DS (важно – именно для DS). То есть, главная интересующая нас подпись содержится в корне, это RRSIG over DS (RRSIG от DS). Напомню, что DS-запись содержит значение хэш-функции ключа, относящегося к делегируемой зоне (то есть, в случае нашего примера, к .org). Подпись RRSIG сгенерирована при помощи корневого ZSK (Zone Signing Key, ключа подписи зоны), который опубликован в корневой зоне, и его нужно будет оттуда получить, чтобы проверить подпись на DS. (Ключ также может уже находиться в кэше резолвера, тогда запрашивать его у корневых серверов не нужно.)

В дальнейшем, информацию, полученную с сервера имён (NS) домена org, мы проверяем ключами, которые опубликованы в этой же зоне (в .org). То есть, RRSIG-и из данной зоны проверяются ключами, которые в той же зоне и расположены. Для связывания ключей из разных зон в цепочку доверия служат DS-записи, которые также подписываются.

Посмотрим чуть ближе на реальное устройство DNSSEC для .org, как всё выглядит сейчас:

1.

В корне (в корневой зоне) мы видим два ключа (я буду их обозначать реальными идентификаторами, которые я взял из DNS) – 22603 (ZSK) и 19036 (KSK – кстати, не менялся с 2010 года, потому что забыли придумать, как его поменять). Для ключа 22603 в корневой зоне есть RRSIG, сгенерированная от ключа 19036. 19036 – это и есть тот самый главный, корневой, рутовый KSK, открытая часть которого изначально находится у нас в резолвере (пусть ключ и опубликован в DNS, но в резолвер он должен попасть каким-нибудь другим доверенным путём, не черезе DNS). После того, как мы проверили RRSIG от ключа 22603 этой открытой частью ключа KSK (19036) и всё сошлось, мы добавляем ключ 22603 в доверенные ключи. И можем пойти дальше.

2.

В корне же мы видим DS-записи для ORG, а также RRSIG для них. Подпись (RRSIG over DS) сделана от ключа 22603 (то есть, от ZSK, см. выше). Ключ 22603 мы только что добавили в доверенные. Проверяем подпись на DS-записи, если всё сошлось, то можем пойти дальше, записав себе значение DS.

3.

На серверах, поддерживающих .org, мы видим четыре ключа – 9795, 21366 (эти два – KSK) и 60764, 11112 (а эти два – ZSK; KSK от ZSK отличаются значением одного бита в поле типа ключа). Хэш от ключа 21366 соответствует значению DS-записи, опубликованной в корне (см. выше). Эту запись мы только что (ну или некоторое время назад, см. TTL) получили от корневого сервера, вместе с подписью, которую проверили – значит, DS-у доверяем.

4.

На серверах .org мы также видим записи (их сейчас три) RRSIG для набора DNSKEY. Эти три записи RRSIG сгенерированы от трёх ключей: 9795, 21366 и 11112 – обратите внимание, каждая из этих RRSIG подписывает все ключи, опубликованные в зоне (ключи публикуются в записях DNSKEY). То есть, у нас четыре ключа подписаны при помощи трёх других. Один из этих подписывающих ключей – 21366 – соответствует DS-записи, полученной из корня, поэтому мы можем добавить его в список доверенных ключей. Теперь записям, подписанным этим ключом, мы тоже будем доверять. После того, как мы убедились, что подпись от ключа 21366, сделанная для RRSIG DNSKEY в зоне .org, – валидная, мы добавляем и три других ключа (9795, 11112, 60764) в список доверенных. Почему? Потому что RRSIG over DNSKEY удостоверяет и их тоже – она для всех ключей зоны общая.

5.

Итак, мы решили получить SOA-запись (это главная запись в любой DNS-зоне) от .org и проверить её. Нет ничего проще: получаем SOA, вместе с ней приходит RRSIG, сгенерированная от ключа 11112, этот ключ есть у нас в списке доверенных, поэтому проверяем подпись – если сходится, то верим данным из SOA-записи. (Аналогично – для А-записей и для прочих.)

Обратите внимание, что мы не проверяли подписи на адресах NS-ов (серверов имён .org) – этого и не нужно делать, если только мы не хотим проверить именно значения NS-ов. Хитрость в том, что в DNSSEC не имеет значения, откуда были получены подписанные данные – с легитимных серверов или ещё откуда-нибудь: главное, чтобы подписи сходились.

Резюме: информацию, получаемую с серверов .org, мы проверяем ключами, полученными с тех же серверов, а вот убедиться, что это правильные ключи, нам позволяет подпись (RRSIG over DS) из корневой зоны.