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

Из имён .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) из корневой зоны.

Схема организации подписей и зон DNSSEC для dxdt.ru:

Картинка сгенерирована при помощи полезного сервиса DNSViz.

Кстати, довольно давно я завёл специально испорченную, в смысле DNSSEC, зону – dotsu.su. С её помощью удобно тестировать различные анализаторы DNSSEC. Текущая версия DNSViz выдаёт вполне корректную картинку для dotsu.su (раньше были сбои).

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

Конечно, есть персональные аккаунты на разных сайтах, но их всё равно заводит компьютер, хоть и, вероятно, на основе команд пользователей. Вопрос с идентификацией реальных людей, а не компьютеров, принципиален для массовой интернет-слежки: источник активности в Сети должен быть точно известен. Процитирую свою статью в “Доменных именах”:

Если точной дифференциации источников нет, а ваша система не умеет отличать одного гражданина от другого, то следы начинают путаться, потому что деятельность двух различных граждан в Интернете оказывается приписана одному собирательному образу. Эта оплошность тут же рушит общую картину, ведь носителя этого собирательного образа в мире не существует. Это означает, что построенный поведенческий профиль будет содержать большую ошибку, что потянет за собой проблемы с предсказанием действий и, на следующем шаге, с сопоставлением новых следов, найденных в трафике. Аналитика, работающая на пользовательском трафике, сложна, а ее алгоритмы содержат много внутренних связей. Так что, если на одном участке базы данных ваша система не смогла отличить Петра Владимировича от Владимира Петровича, будьте уверены: из-за этого на другом участке базы данных перепутаются Ольга Семеновна и Марина Ивановна.

Ещё немного про TLS/SSL: Let’s Encrypt – это инициатива по созданию общедоступного бесплатного удостоверяющего центра (УЦ), а также программных инструментов и сервиса автоматической выдачи сайтам SSL-сертификатов, признаваемых браузерами. Более того, обещают, что сопутствующее ПО будет автоматически настраивать веб-сервер для работы по HTTPS.

Чуть подробнее: предполагается, что утилита Let’s Encrypt, будучи запущенной на сервере, сама сгенерирует ключи, свяжется с удостоверяющим центром, подтвердит управление сайтом (владение доменом), закажет и получит SSL-сертификат и настроит веб-сервер для работы с ним. Всё это с использованием специального протокола, который был разработан ранее. И бесплатно.

Выглядит, конечно, привлекательно. Но вызывает сомнение высокая степень автоматизации: всё ж SSL/TLS иногда требует обдумывания действий, иначе безопасность не повышается, а скорее наоборот. Всякое тиражное решение несёт с собой риск тиражирования не только хороших, правильных практик, но и ошибок, которые сделали разработчики решения. Можно спорить, насколько сильно нужно ошибиться в сервисе, автоматически внедряющем HTTPS на сервере, чтобы в результате ошибки уровень безопасности для этого сервера снизился – предполагается, что до момента запуска Let’s Encrypt сервер вообще использовал открытый протокол HTTP. Всяческие сценарии с захватом управления веб-сервером и автоматическим выпуском сертификата для его домена не очень пугают, так как если кто-то получил управление сервером, то он и так может сделать с ним всё что угодно, в том числе заказать сертификат (тут, впрочем, может потребоваться ещё и контроль электронной почты под доменом). Но, естественно, бесплатность процедуры несколько упрощает атаку.

Нет сомнений, что подобный сервис, к сожалению, окажется удобен для различных фишерских доменов, среди которых есть и простые тайпсквотерские (yanclex.ru), и более хитрые, комбинированные: например, что-нибудь вроде ssl-yandex.ru. Возможность быстро выпустить бесплатный сертификат и поднять HTTPS, вызывающий дополнительное доверие пользователей – она не может быть лишней. Впрочем, сейчас для этих же целей успешно выпускаются платные сертификаты DV (с валидацией по домену), с подставными реквизитами: возможности определить степень легитимности домена УЦ не имеет. Так что радикально Let’s Encrypt тут ситуацию не изменит.

Запуск сервиса обещают летом 2015 года. В числе участников инициативы значатся Mozilla и IdenTrust (это действующий УЦ), то есть можно ожидать появления нового УЦ как минимум в одном распространённом браузере. Как я понимаю, на первых порах Let’s Encrypt планирует вообще использовать для работы корень IdenTrust, с отдельным промежуточным сертификатом (по крайней мере, сейчас у них на сервере HTTPS устроен именно так). В общем, посмотрим, что получится.