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

В экспериментальной версии Google Chrome добавлена поддержка “постквантовых” алгоритмов в TLS. “Постквантовая криптография” – это собирательный термин, обозначающий криптосистемы и отдельные алгоритмы, для которых не известно быстрых методов взлома на квантовом компьютере, либо доказано, что таких методов нет (строгое требование доказанного отсутствия возможности “квантового взлома” не является обязательным).

При выборе средств криптографической защиты информации исходят из того, насколько долго информацию нужно хранить в секрете. Если гипотетический квантовый компьютер ожидается через десять лет, это означает, что записанный ранее трафик – может быть расшифрован. Если вы планируете, что защищаемая информация останется недоступной и через десять лет, то переходить на стойкие алгоритмы нужно уже сейчас. При этом со старыми сообщениями, защищёнными, например, PGP – поделать ничего нельзя: если они сохранились, то их прочитают. То же самое можно сказать и о трафике TLS.

Вообще, пока никто не продемонстрировал на практике для сколь-нибудь мощных квантовых компьютеров работу алгоритмов, составляющих угрозу для асимметричных криптосистем. Таких компьютеров просто нет (устройства D-Wave не считаются, так как они не подходят). Учитывая, что вся вычислительная мощь данных алгоритмов кроется в физических свойствах окружающей действительности, нельзя исключать, что задача создания подходящего квантового компьютера окажется несравнимо труднее, чем принято считать сейчас: до сих пор нельзя со полной уверенностью сказать, что компьютер с 1024 кубитами вообще возможен практически. С другой стороны, одно дело – полная уверенность, а совсем другое – быстрое развитие прикладной науки. Так что угроза появления квантового компьютера достаточной мощности считается реальной уже сейчас, по этому поводу есть публикации NIST.

Используемый сейчас в TLS (и других приложениях) протокол Диффи-Хеллмана, обеспечивающий прогрессивную секретность, в случае квантового компьютера оказывается вообще не защищённым. Соответственно, сеансовые ключи можно будет извлечь из записи сессий, несмотря на то, что они не зашифровывались RSA. Симметричные шифры – в лучшем положении: влияние “квантового ускорения” здесь минимально.

В Chrome добавили постквантовый протокол с рабочим названием New Hope, позволяющий сторонам договориться о сеансовых ключах. Вообще, в основе этой схемы (являющейся вариантом Ring-LWE, где LWE – это алгоритм Learning With Errors, реализованный для решётки, а кольцо там появляется из-за используемой арифметики и коэффициентов; но технические подробности я оставляю для другой записки) лежит та же математическая идея, что и в протоколе Диффи-Хеллмана. Однако принципиально иной фундамент позволяет добиться требуемой постквантовой стойкости. Почему для эксперимента выбрана схема получения сеансовых ключей? Отложенные атаки важны только для защиты ключей шифрования, а не для защиты аутентификации. Действительно: какой смысл во взломанной спустя год схеме аутентификации? Подменить узел постфактум – не получится. А вот раскрытие ключей симметричного шифра позволяет прочитать трафик. И, кроме того, с постквантовой аутентификацией ситуация обстоит несколько хуже, чем с алгоритмами распределения ключей.

Пока не понятно какие именно постквантовые схемы войдут в состав TLS и когда это произойдёт. Для полноценной замены имеющихся инструментов потребуется схема аутентификации, вместо RSA и ECDSA в SSL-сертификатах. Тут квантовый компьютер превращает сложившуюся практику в “тыкву”: раскрыв секретный ключ сервера, можно активно перехватывать сессии в его направлении. Не исключено, что поменяется сама логика распределения ключей.

Думаю, что нужно вспомнить про квантовую криптографию, которую часто упоминают в качестве средства противодействия квантовым атакам на криптографию “классическую”. Квантовая криптография – это метод распределения ключей, позволяющий обнаруживать, на физическом уровне, пассивное вмешательство в канал. То есть, “квантовый” канал здесь в некоторой степени гарантирует, что биты ключа не были измерены третьей стороной. Что касается оборота “в некоторой степени”: конечно, если рассуждать в рамках теоретической модели процесса, то стойкость схемы получается абсолютной, так как обнаружение измерений гарантируется физическими законами. К сожалению, на практике всякие схемы распределения ключей оказываются подвержены техническим уязвимостям. Примеров довольно много. Они начинаются от электрического эха переключения реле, которое попадало на магнитную ленту с зашифрованной абсолютно стойкой криптосистемой записью и соответствовало состоянию битов открытого текста. Конца и края этим примерам не видно. Кроме того, квантовые каналы очень дорогие, имеют ограниченное использование (их никак нельзя организовать между произвольными ПК) и наверняка доставляют немало проблем при обслуживании и сопровождении. Поэтому пока что вся надежда на чисто математическую постквантовую криптографию.

(Поделюсь на dxdt.ru такой репликой про “ключи и шифрование”.)

Вот про что ещё забывают. Криптография, кроме сокрытия информации (шифрование), предоставляет инструменты обеспечения целостности передаваемых сообщений (это, грубо говоря, защита от подмены данных). Для множества новых протоколов связи – это важнейшая вещь, потому что только она и позволяет обеспечить надёжность работы сети, защитить её от атак. Речь не столько о “сообщениях пользователя”, которые для сетевого протокола значения не имеют, сколько об адресах и служебных полях передаваемых пакетов. Это хорошо иллюстрирует пример одноранговых меш-сетей. Здесь необходима возможность использования сети в случае, если часть составляющих её узлов являются злонамеренными и проводят активные атаки. Без криптографии – реализация подобных технологий невозможна. А если технологию защиты не реализовать, то сеть может быть легко выведена из строя. В этом направлении свою роль играет и шифрование, но его использование необходимо для сокрытия части информации от активных атакующих участников обмена данными. Это делается для того, чтобы кардинально ограничить их возможности по проведению атак на сеть, а вовсе не для того, чтобы скрыть содержание самого сообщения (которое, впрочем, тоже может быть зашифровано). Для обеспечения целостности, как и для шифрования, требуется набор секретных ключей, которые находятся на узлах, осуществляющих обмен данными. При этом всякая схема центрального распределения ключей (хоть такие схемы и хорошо отработаны) оказывается в жёстком противоречии с одноранговой архитектурой сети: отдельный узел, желающий передать данные, перед началом работы скорее всего не имеет доступа к центру выдачи ключей, а чтобы безопасно воспользоваться сетью – требуются ключи.

Нередко спрашивают, что такое DNSCrypt и зачем это нужно. Некоторое время назад я уже писал про DNSCrypt, применительно к “Яндекс.Браузеру”, тогда речь шла о поддержке в бета-версии браузера. В этот раз посмотрим на технологию в подробностях, а “Яндекс.Браузер” послужит примером и источником лабораторных данных. Разбор пакетов я провожу в Wireshark, для которого написал небольшой парсер DNSCrypt (в терминологии Wireshark – это dissector, на языке Lua; штатного парсера DNSCrypt в Wireshark-е мне выявить не удалось).

DNSCrypt – это прокси-сервис, создающий защищённый канал между клиентским резолвером DNS и рекурсивным DNS-резолвером, исполняемым на сервере. У DNSCrypt, соответственно, две части: клиентская и серверная. Через трафик DNS, который штатно передаётся в открытом виде, могут утекать сведения о посещаемых сайтах. Кроме того, запросы DNS – распространённый вектор атак для подмены адресов. Замена адреса системного резолвера DNS на адрес подставного сервера является общим местом троянских программ уже много лет. То же самое относится к атакам на домашние роутеры. DNSCrypt позволяет зашифровать (а также – ограниченно защитить от подмены) и запросы, и ответы DNS. Предусмотрена возможность аутентификации сервера и клиента, но эта возможность не всегда используется. Вообще, тема сокрытия DNS-трафика (DNS Privacy) сейчас набрала заметную популярность. Кроме DNSCrypt, существует, например, протокол “DNS через TLS” (DNS over TLS – свежий RFC 7858, который, несмотря на некоторую “перевёрнутость”, выглядит не хуже DNSCrypt). Есть и другие разработки.

DNSCrypt. Протокол может использовать в качестве транспорта как TCP, так и UDP. На практике, предпочтение отдаётся UDP, если он доступен, но спецификация строго требует поддержки именно TCP (не UPD, поддержка которого опциональна). TCP, естественно, привлекает сессионной природой. Но UDP – гораздо быстрее, особенно для нагруженных сервисов. Из-за проблем с DDoS-атаками и некоторых других вопросов обеспечения безопасности, сейчас наметилось модное движение в сторону перевода максимального числа сервисов на TCP, это особенно касается DNS. Тем не менее, ниже я рассматриваю работу DNSCrypt только по UDP, так как это традиционный для DNS вариант. Рекомендованный номер (серверного) порта DNSCrypt – 443 (он обычно открыт в корпоративных сетях; практика использования 443/udp, например, является стандартной для целого ряда VPN и других сервисов; 443/tcp – это TLS/HTTPS, фундамент веб-сервисов). Впрочем, “Яндекс” в своей реализации DNSCrypt использует непривилегированный номер: 15353, вероятно, это связано с какими-то идеями по преодолению разнообразных сетевых барьеров.

Чуть подробнее о барьерах: никаких проблем с блокированием трафика DNSCrypt, при наличии такого желания у провайдера канала, не возникнет. Как будет ясно из описания ниже, этот протокол никак не пытается скрыть сам факт своего использования. В трафик данного протокола включаются стандартные маркеры, которые позволят обнаружить и зафильтровать пакеты даже на самом примитивном маршрутизаторе, с помощью нехитрого правила “в две строчки”. При этом, например, доступ для других TCP-сессий, работающих на 443 порту, сохранится.

В DNSCrypt установление сессии между клиентом и сервером начинается с обычного DNS-запроса, отправленного на адрес и соответствующий номер порта узла, который будет предоставлять функции резрешения (резолвинга) имён. Это запрос TXT-записи для имени специального вида (то есть, запрос уже можно легко зафильтровать). Например, в случае с сервисом “Яндекса”: 2.dnscrypt-cert.browser.yandex.net. Это специальное имя может быть не делегировано. Значение 2 – соответствует версии DNSCrypt. Актуальная версия – вторая. В ответ сервер должен прислать один или несколько сертификатов DNSCrypt (подчеркну: они не имеют никакого отношения к SSL-сертификатам).

На скриншоте – пакет с сертификатом от сервера DNSCrypt “Яндекса”.

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

Спецификация предполагает, что в составе сертификата сервер передаёт кратковременный открытый ключ. (Впрочем, в случае с сервером “Яндекса”, данный ключ не меняется, как минимум, с конца марта, когда была запущена бета-версия браузера с поддержкой DNSCrypt.) Подпись на сертификате должна генерироваться от другой пары ключей. Открытый ключ этой пары известен клиенту – он необходим для проверки подписи. Очевидно, подписывать сертификат тем же ключом, который используется в рамках сессии – бессмысленно. Я не проверял, проводит ли валидацию серверного сертификата “Яндекс.Браузер”. Дело в том, что в модели угроз, на которую ориентировано использование DNSCrypt в “Яндекс.Браузере”, валидация сертификата особого смысла не имеет, как и сравнение значения ключа с сохранённой копией (я вернусь к этому моменту ниже).

В качестве криптографических примитивов DNSCrypt использует конструкции из шифра Salsa20 (XSalsa20), хеш-функции Poly1305 (для реализации аутентифицированного шифрования) и алгоритм X25119-hsalsa20 для выработки общего сеансового ключа (алгоритм использует эллиптическую кривую Curve25119 и хеш-функцию hsalsa20). Эти конструкции разработаны Даниэлем Бернштейном (Daniel J. Bernstein) и давно получили признание как весьма добротные. Алгоритм получения общего секрета (сеансового ключа) математически родственен алгоритму Диффи-Хеллмана. Отмечу, что общий секрет в данном случае можно восстановить постфактум, если станет известен соответствующий секретный ключ из пары серверных (или клиентских) ключей, это позволит расшифровать ранее записанный трафик, именно поэтому спецификация рекомендует использовать кратковременные ключи.

Шифр XSalsa20 в режиме аутентифицированного шифрования требует nonce длиной 192 бита (24 байта). Повторное использование одного и того же сочетания ключа и nonce не допускается. Это связано с архитектурой шифра XSalsa20 – повторное использование nonce приведёт к утечке: прослушивающей стороне станет известно значение XOR от пары соответствующих открытых текстов. Поэтому nonce должно быть каждый раз новым, но не обязательно случайным. Параметр nonce в DNSCrypt присутствует в двух воплощениях: клиентской и серверной.

Посмотрим на зашифрованный клиентский запрос, отправляемый “Яндекс.Браузером”.

Первое поле запроса – это клиентское значение magic (Client query magic bytes): здесь используется часть открытого ключа сервера, полученная ранее. При необходимости, данные “магические байты” могут служить сигнатурой, позволяющей выбирать в трафике запросы, отправляемые к DNSCrypt;
Следующее поле – кратковременный клиентский открытый ключ (Client public key);
Клиентское значение nonce – 96 бит (12 байтов), половина от требуемого значения nonce для шифра XSalsa20 (согласно спецификации DNSCrypt, дополняется байтами со значением 0). Можно использовать тот или иной счётчик, “Яндекс.Браузер” так и поступает: cудя по всему, здесь передаётся 64-битное значение миллисекундного таймстемпа (время формирования запроса), к которому дописываются четыре байта псевдослучайных значений. На случай, если это действительно точное время, передаваемое в открытом виде, отмечу, что параметры дрейфа системных часов служат неплохим признаком, идентифицирующим конкретное аппаратное устройство, – то есть, могут быть использованы для деанонимизации;
Последнее поле – это сам зашифрованный запрос. Для шифрования используется общий секретный ключ, который вычисляется сторонами на основании переданных открытых ключей. В случае с клиентом – открытый ключ передаётся в пакете DNS-запроса (см. выше). “Яндекс.Браузер” следует стандартной практике и генерирует новую пару ключей (открытый/секретный) для X25119-hsalsa20 при каждом старте барузера. Для выравнивания данных на границу 64-байтового блока, как предписывает спецификация, используется стандартное дополнение (ISO/IEC 7816-4: 0x80 и нулевые байты в требуемом количестве).

Блок зашифрованных данных – это, скорее всего, результат использования функции crypto_box из библиотеки libsodium (либо NaCl, на которую ссылается спецификация DNSCrypt; libsodium – это форк NaCl). Я предположил, что 16-байтовый код аутентификации (MAC), который используется для проверки целостности сообщения перед расшифрованием, находится, вероятно, в начале блока. Впрочем, так как расшифровать данные я не пытался, то и определение расположения кода не столь важно. Для расшифрования можно использовать секретный ключ, который содержится в памяти во время работы браузера, но чтобы его извлечь – нужно некоторое время повозиться с отладчиком и дизассемблером.

Зашифрованный ответ, полученный от сервера:

(Нетрудно заметить, что ответ, представленный на скриншоте, поступил почти через пять секунд после запроса, почему так получилось – видимо, тема для отдельной записки.)

Пакет открывается magic, в данном случае, это байты, содержащие маркер ответа DNSCrypt (опять же, хорошая сигнатура для обнаружения трафика). Эти байты определены протоколом и должны присутствовать в начале всякого ответа сервера на запрос DNS-резолвинга;
Следующее поле – nonce (Response nonce). Поле содержит значение nonce, использованное сервером при шифровании данного ответа. Поле строится из двух равных частей, по 12 байтов: nonce из соответствующего клиентского запроса и серверное дополнение;
Заключительная часть пакета – зашифрованные данные ответа, формат аналогичен запросу.

Теперь вернёмся к модели угроз, на примере “Яндекс.Браузера”. Если в настройках браузера включено использование DNSCrypt, например, через серверы “Яндекса”, но доступ к соответствующему серверу заблокирован, то браузер (как и бета-версия) прозрачно, без предупреждений, переходит к использованию системного резолвера. Почему это лишает смысла необходимость валидации сертификатов серверов DNSCrypt? Потому что активная атакующая сторона, которая может подменять пакеты на уровне IP, для отключения DNSCrypt в браузере может просто заблокировать доступ к серверу, вместо того, чтобы тратить ресурсы на поделку ответов. Из этого можно сделать вывод, что модель угроз “Яндекса” не включает активную подмену пакетов на пути от сервера DNSCrypt к клиенту.

В качестве завершения, пара слов о том, как DNSCrypt относится к DNSSEC. DNSSEC – не скрывает данные DNS-трафика, но защищает их от подмены, вне зависимости от канала обмена информацией. В случае с DNSSEC – не имеет значения, по какому каналу получены данные из DNS, главное, чтобы ключи были на месте. DNSCrypt – скрывает трафик и ограниченно защищает его от подмены на пути от рекурсивного резолвера (сервиса резолвинга) до клиента. Если данные были подменены на пути к резолверу (или на самом сервере резолвера), а он не поддерживает DNSSEC, то клиент получит искажённую информацию, хоть и по защищённому DNSCrypt каналу. Серверы, предоставляющие DNSCrypt, могут поддерживать и DNSSEC.

В декабре прошлого года я описывал тонкости реализации прозрачного перехвата TLS. Кроме прочего, в той записке есть и фрагмент про перехват с участием УЦ, но когда УЦ секретные ключи на отдаёт третьей стороне (чтобы меньше нарушать требования). Цитата:

Если договориться с провайдером сервиса не удаётся, то возможен другой вариант: участие хорошо известного удостоверяющего центра (УЦ). “Хорошо известного” – в том смысле, что признаваемого браузерами (в случае с HTTPS). Схема с выпуском перехватывающих промежуточных сертификатов – тоже хорошо известна, некоторые УЦ на этой схеме даже попадались. SSL-прокси может взаимодействовать с УЦ следующим образом. Прокси перехватывает TLS-соединение в момент установления, после чего отправляет на специальный API УЦ запрос с сетевым именем, к которому обращается клиент. УЦ известен секретный ключ, который прокси использует при перехвате. УЦ в режиме онлайн выпускает “короткоживущий” сертификат (например, валидный в течение суток) для ключа прокси и требуемого сетевого имени. Этот сертификат возвращается в качестве ответа API. Далее SSL-прокси использует его для подмены и, таким образом, выдаёт себя за узел, с которым пытался соединиться клиент.

На днях занятную схему “вдруг” обнаружили у УЦ Symantec, об этом пишет The Register. Symantec (ещё в прошлом году) выпустили промежуточный сертификат УЦ для Blue Coat (под этой маркой поставляются SSL-прокси для инспектирования TLS-трафика). При этом Symantec утверждает, что ключи от данного сертификата не покидали пределов систем компании, а практика с выпуском корпоративных промежуточных УЦ является стандартной. С последним, между прочим, не поспоришь: действительно, УЦ вполне могут выпускать подобные партнёрские сертификаты.

Positive Technologies подтвердили известную вещь: при помощи перехвата SMS можно получить доступ к аккаунтам мессенджеров, даже тех, которые продвигаются как особенно защищённые. В ответ появляются статьи, где пишут, что сами мессенджеры всё равно защищённые, это виноват транспорт, канал связи (все показывают в сторону операторов). Например, подзаголовок статьи The Register гласит: WhatsApp, Telegram secure – but the transport isn’t (хотя цитаты в самой статье об этом не говорят).

Картина полностью копирует давнюю ситуацию, когда считалось, что пароли можно передавать по HTTP в открытом виде, потому что должны быть защищены от прослушивания каналы связи, по которым “работает Интернет”. Вообще, в GSM есть проблемы, в том числе, происходящие из того, что система межоператорского взаимодействия (откуда и растёт набор сигналов SS7), использующаяся для обмена данными об абонентах и для управления сетью, построена на доверии (то же самое, кстати, касается и маршрутизации в Интернете – BGP). Это всё давно известно. Также как давно известно, что можно прослушать телефонный разговор по обычному проводному телефону, если подключиться к проводам. Но разработчики “защищённых” мессенджеров должны бы учитывать эту возможность. Ведь они научились использовать шифрование при передаче сообщений, признали, так сказать, открытые каналы открытыми. Операторы связи вряд ли станут исправлять ситуацию в обозримом будущем – в этом нет смысла. А полагать, что оператор должен защищать все мыслимые сервисы своего абонента, которые прямо или косвенно используют сеть GSM, – несколько наивно.

В бета-версии “Яндекс.Браузера” появилась поддержка DNSCrypt. Посмотрим, как она работает. Для активации – нужно включить опцию “Всегда использовать … DNSCrypt” в настройках браузера (опция, похоже, доступна только в версии под Windows). После этого браузер начинает использовать сервер “Яндекс.DNS”, с IP (в моём случае) 77.88.8.78, отправляя запросы DNSCrypt по UDP на номер порта 15353. Сессия DNSCrypt, согласно протоколу, начинается с отправки пакета, содержащего в открытом виде имя сервера и версию протокола: 2.dnscypt-cert.browser.yandex.net. Данный запрос необходим для получения сертификата сервера и генерации криптографического контекста, который далее будет использоваться клиентом и сервером для шифрования запросов/ответов. Вообще, протокол DNSCrypt не ставит задачи сокрытия самого факта использования DNSCrypt, поэтому может быть легко блокирован с использованием системы DPI. Трафик DNSCrypt “Яндекс.Браузера”:

Но самое занимательное, что если просто заблокировать доступ к 77.88.8.78, то бета-версия браузера в прозрачном режиме (молча, без каких-либо уведомлений) переходит на штатный системный резолвер, игнорируя опцию DNSCrypt в настройках (“Яндекс” про это прямо пишет). Вообще говоря, такое положение дел позволяет провайдеру, желающему перехватывать DNS-запросы, заблокировать доступ к “Яндекс.DNS” и продолжить вмешиваться в трафик. То же самое может сделать и “взломанный домашний роутер”. То есть, в заявленной “модели угроз”, такое решение по внедрению DNSCrypt с защитой не справляется никак: “злой провайдер” последней мили сможет легко и незаметно отключить использование DNSCrypt. (Отмечу, что “Яндекс” собирается с этим побороться: прямо запретив такой “даунгрейд” протокола.)

Естественно, в реализации DNSCrypt могут быть уязвимости, начиная от некорректной аутентификации сервера (протокол предусматривает двухстороннюю аутентификацию, вопрос в том, как она реализована в браузере “Яндекса”) и до различных дефектов и утечек, связанных с генерацией и использованием ключей.

Про перехват TLS я уже писал, например, применительно к HTTPS, а также касательно некоторых технических особенностей, обеспечивающих прозрачность перехвата TLS. Продолжим тему технических деталей. Пусть требуется пассивно читать трафик TLS, сервис-провайдер готов участвовать, но не имеет возможности предоставить внешний API для доступа к ключам, как быть? Есть известное решение, но оно требует некоторого бэкдора.

Идея состоит в том, чтобы значение ключа можно было восстановить из самого защищённого трафика. Напомню, что трафик TLS защищается при помощи симметричного шифра и сеансового ключа. В современных реализациях сеансовый ключ генерируется сторонами по протоколу Диффи-Хеллмана (классического или на эллиптических кривых), который и обеспечивает защиту сессии. Какие секретные параметры нужно знать, чтобы вычислить сеансовый ключ? Такой параметр лишь один – это экспонента Диффи-Хеллмана (DH), используемая сервером (или экспонента клиента). Действительно, если прослушивающая канал сторона знает экспоненту (являющуюся в протоколе Диффи-Хеллмана секретным ключом сервера), то она может вычислить общий сеансовый ключ так же, как это делает сервер или клиент. Осталось понять, как можно передать значение экспоненты, например, с сервера “в эфир”, чтобы не догадались те, кто канал не должен прослушивать. Для этого в TLS есть целый ряд способов. Самый простой – это поле ServerRandom, которое содержит случайное значение длиной в 32 байта (256 бит) и передаётся в открытом виде. В этом поле может быть передано состояние генератора псевдослучайных чисел, который используется для выбора значения секретного значения протокола Диффи-Хеллмана. Зная состояние генератора – третья сторона сможет определить это секретное значение.

Осталось придумать, как сохранить в секрете возможность прослушивания – чтобы расшифровать данные мог только тот, “кому следует”. Для этого оператору сервера передаётся открытый ключ (например, в качестве типового параметра настроек), который он использует для зашифрования состояния генератора, перед тем, как передать его в поле ServerRandom на всеобщее обозрение. Кстати, 256 бит – это слишком мало для RSA, но вполне достаточно для эллиптических кривых, поэтому в качестве механизма защиты может использоваться какая-нибудь разновидность криптосистемы Эль-Гамаля на эллиптических кривых. Считается, что именно этот способ предполагался на роль бэкдора в нашумевшем случае DUAL_EC_DRBG. Естественно, зашифрованный параметр в ServerRandom практически неотличим от случайного числа – чтобы что-то понять, нужно знать секретный ключ, который неизвестен даже серверу-источнику перехватываемого трафика. (Передача ключей в ServerRandom – не единственный способ.)

При данной схеме третья сторона прослушивает канал, записывает трафик, а при необходимости – расшифровывает его без участия провайдера сервиса. То есть, последний никак не будет “скомпрометирован”. В этом отличие от схемы с предоставлением API, наличие которого, во-первых, раскрывает намерения провайдера, во-вторых, компрометирует перечень прослушиваемых каналов, так как каждому подключению соответствует обращение к API, которое можно зафиксировать в логах. Бэкдор с публикацией ключа DH – позволяет действовать в пассивном режиме. На стороне сервера раскрыть такой бэкдор может только анализ исходного кода, если не были предприняты дополнительные меры по защите, вроде выноса части криптофункций в аппаратный модуль (HSM), но это история для другой заметки.

“Яндекс” добавили в свой браузер (в бета-версию) поддержку DNSCrypt. Это шифрующая и аутентифицирующая обёртка для DNS, позволяющая не только проверить, что адресная информация не была подменена (подменена – на пути от резолвера до клиента, это важно), но и скрыть содержание запроса ответа от просмотра узлами, находящимися между клиентом и рекурсивным резолвером (сам резолвер, естественно, о запросах знает).

Для работы сервиса нужно использовать резолверы “Яндекса”. Какую дополнительную информацию это даёт “Яндексу”? Он видит адреса сайтов, на которые (потенциально) заходит пользователь браузера. Вообще, в случае с “Яндекс.Браузером”, нельзя сказать, что “Яндекс” прямо вот так ничего не видел раньше: браузер легко так настроить, что он посещаемые пользователем адреса (доменные имена) будет отправлять на сервера компании при установлении соединения (для проксирования, или для проверки – не важно). При помощи DNS, разве что, можно видеть адреса, запрашиваемые теми пользователями, которые все другие способы отправки сведений в “Яндекс” отключили.

DNSCrypt – технология “последней мили”, которая позволяет создать защищённый канал между рекурсивным резолвером и клиентским ПО. То есть, вмешиваться в ответы (и запросы) DNS не сможет интернет-провайдер. Но технология не гарантирует, что подмены не произойдёт где-то ещё. Впрочем, случаи “где-то ещё” чрезвычайно редки, а вот подмена на “последней миле” – встречается, к сожалению, часто.

Интересно, что качественная реализация DNSCrypt должна подразумевать аутентификацию сервера – иначе провайдер может точно также, как и в случае “обычного” DNS, завести трафик на свой перехватывающий сервер, но добавить там поддержку DNSCrypt.

И, видимо, весьма интересную статистику может построить “Яндекс”, сопоставляя запросы DNS с данными “Яндекс.Метрики”, установленной на просматриваемых пользователем сайтах.

Считается, что привязка аккаунта в том или ином онлайн-сервисе к телефонному номеру увеличивает степень защиты этого аккаунта от перехвата. С Facebook недавно обнаружилась показательная уязвимость, очередной раз подтверждающая, что это не всегда так.

Описанная Пракашем атака основывается на используемом в Facebook механизме смены пароля. Желая изменить его, пользователь должен сообщить администрации свое имя, имя учетной записи, а также адрес электронной почты и номер телефона. На этот номер высылается 6-значный цифровой код, ввод которого и позволяет сменить пароль.

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

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

В рамках проекта КЦ и ТЦИ “Домены Россиии” (statdom.ru) – мы добавили статистику TLS по российским зонам. (Официальная новость.) Приведено несколько основных отчётов, позволяющих понять, как развивается HTTPS: общая статистика, а также данные по алгоритмам и ключам. Данные собираются именно для HTTPS – то есть, это 443/tcp. Приведены результаты, начиная с июля прошлого года (2015). У меня на dxdt.ru есть некоторые данные по TLS/SSL в Рунете за 2011 год, это почти пять лет назад (да и методика сбора там другая). За это время, например, число самоподписанных сертификатов сократилось более чем в два раза: 52173 (тогда) против 23931 (сейчас). А ECDSA тогда просто не было.

Если посмотреть в выборку по корректным HTTPS-узлам (это узлы, вернувшие валидный сертификат, совпавший по имени), то видно, как стремительно растёт проникновение HTTPS: за семь месяцев в зоне .RU число HTTPS-узлов выросло почти, примерно, на 21 тыс. с 34205 до 55781. Из новинок: Let’s Encrypt – добавляет почти по тысяче в месяц, это видно в отчёте по Top 10 удостоверяющих центров.

Методика кратко описана на соответствующей странице statdom.ru.

В самом конце прошлого года вышел второй номер журнала “Интернет изнутри” (он издаётся при поддержке “МСК-IX”). Журнал рассказывает детали о технологиях, лежащих в основе Сети, посвящая читателя (предполагается, что это достаточно подготовленный читатель) в особенности применения тех или иных решений. Например, во втором номере – статьи про утечки маршрутов (BGP) и рефлекторные атаки. В этом номере также опубликована моя большая статья про TLS: “TLS: двадцать лет спустя”. Журнал доступен в формате PDF на сайте – рекомендую.