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

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

Так как появились странные (невнятно сформулированные) слухи о недоступности DNS от Google из Рунета, я померил доступность при помощи сервиса RIPE Atlas – доступ есть, вот результат, на карте:

Измерение я проводил для 8.8.8.8, через 252 RIPE-зонда (probes), расположенных в Москве и ближайших регионах, в качестве запроса использовалось имя iana.org. Полученный адрес (верный) указан в легенде на картинке.

HPKP (HTTP Public Key Pinning) – технология, позволяющая привязать к серверу открытый ключ. Для этого служит специальное поле в заголовках HTTP. Я писал про HPKP на dxdt.ru ранее. Как и в случае практически любой технологии обеспечения информационной безопасности – интересно посмотреть, как реализация работает в деталях. Для этого я добавил HPKP на “тестовую площадку”: 1d.pw.

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

Отлаживать HPKP непросто. Запись отпечатка производится только в том случае, если браузер успешно установил соединение по TLS и получил ответ с корректно форматированным полем Public-Key-Pins – то есть, требуется работающий по TLS веб-сервер с валидным SSL-сертификатом. Для того, чтобы вызвать ошибку проверки отпечатка также требуется валидный сертификат: иначе браузер выдаст сообщение об ошибке раньше, чем доберётся до проверки отпечатков. При этом требуется серверный сертификат, выпущенный для другого ключа, отличающегося от “правильного”. Как-то узнавать браузер на сервере, чтобы имитировать подмену ключа, – не получится: проверка отпечатка происходит на самом раннем этапе установления TLS-соединения, ни куки-файлы, ни какие-то ещё данные “уровня приложения” к этому моменту переданы не будут. Идентифицировать по IP-адресу в наше время NAT-ов и прочих трансляторов – тоже неправильно.

Я поступил следующим образом. По адресу https://1d.pw/ откликается веб-сервер, который передаёт заголовок с отпечатком ключа и флагом, обозначающим, что отпечаток действителен для всех поддоменов (ниже я привожу поле Public-Key-Pins для 1d.pw полностью). А по адресу https://pin.1d.pw/ – откликается другой виртуальный хост, который использует другой серверный ключ (но в паре с валидным сертификатом). Если ваш браузер ещё не был на 1d.pw, то вы можете с его помощью успешно посетить pin.1d.pw. Однако если ваш браузер зайдёт на https://1d.pw/, то он запомнит отпечаток ключа. Если после этого попытаться открыть https://pin.1d.pw/, то должно появиться сообщение об ошибке (“невозможно установить защищённое соединение” или подобная формулировка) – это означает, что HPKP поддерживается браузером. Время жизни отпечатка указывается в поле Public-Key-Pins – для 1d.pw это 3600 секунд (или 1 час).

Вот заголовок HPKP:

Public-Key-Pins:pin-sha256=”afLVIYy6nD4LIkratYg295p89kYfqChllWQGYs7K8/A=”; pin-sha256=”K/QRriVzZo54i+9qeLPgP+22zWsL4rMZGFU9F0QJn/M=”; max-age=3600; includeSubdomains; report-uri=”http://hpkp-reporter.dxdt.ru/api/hpkp.pl”

Здесь есть ещё один интересный элемент – report-uri. Это адрес, по которому браузер передаёт сообщение о неудачной проверке отпечатка ключа (POST-запрос с данными в формате JSON). Я поднял отдельный обработчик для этих сообщений (планирую вынести его на другой домен и подключить, в том числе, к HKPK на dxdt.ru). Пока что данная функция работает только в Chrome, но это весьма распространённый браузер, поэтому, в теории, можно будет увидеть попытки перехвата TLS-соединений.

Посмотрим, как использование HPKP будет развиваться дальше.

Получается непрерывная серия записок про TLS и связанные технологии, но, тем не менее, продолжу. Добавил на dxdt.ru поддержку технологии под названием HPKP – HTTP Public Key Pinning. Key Pinning – это привязывание публичного ключа к сетевому ресурсу (по имени или по адресу) на стороне клиента. Принцип хорошо известен из практики использования SSH: здесь отпечатки, идентифицирующие серверы, при первом контакте сохраняются на клиенте; в дальнейшем, изменение отпечатка позволит обнаружить возможную подмену ключей в рамках атаки “человек посередине”. Для HTTP предложена технология (RFC 7469), базирующаяся на той же идее.

Веб-сервер передаёт специальное поле в составе заголовков HTTP. Поле содержит отпечатки (значение хеш-функции) публичных ключей, которые используются данным сервером при установлении TLS-соединения, а также время, в течение которого клиенту следует помнить отпечатки. Браузер (то есть, клиент HTTPS), впервые обнаружив отпечатки ключей, запоминает их. При следующих обращениях к данному ресурсу – отпечатки сверяются с переданными ключами: если обнаружено расхождение, то браузер не устанавливает соединение и выдаёт предупреждение системы безопасности. HPKP поддерживается, например, в Chrome и Firefox.

Метод позволяет обнаружить подмену ключей, например, в схеме с выпуском “перехватывающего” сертификата для заданного доменного имени. Дело в том, что узел, перехватывающий TLS, даже если у него имеется валидный сертификат для атакуемого домена, обычно не имеет оригинального секретного серверного ключа – вместо него он использует свой. Значение отпечатка у этого перехватывающего ключа другое, поэтому браузер сможет обнаружить подмену. Если HPKP не использовать, то перехват пройдёт незамеченным, так как цепочка сертификатов будет валидной.

Посмотрим на реализацию подробнее, на примере dxdt.ru:

$ wget -S -O /dev/null https://dxdt.ru/ 2>&1 | grep ‘Public-Key-Pins:’ | tr -s ‘ ‘ | sed ‘s/\;/\;\n/g’

Public-Key-Pins: pin-sha256=”WXeGHAmPHRPwX7CbyIUCQm9mtStbVAZR2LOvTAAQKNg=”;
pin-sha256=”dj2qz8mxs8NSpJdISrUPRfL86ZGu3QNkJm4hL+opE0o=”;
pin-sha256=”nq9/zIb/QKb+tHd1ZU5keAYkYzrA8zx7tMmVtDDNG0M=”;
pin-sha256=”kkwURRddFrj4gRH7ILMp/Fqrvl6kfO4o2ekBOmiP6B0=”;
max-age=270127;

Поле HPKP называется Public-Key-Pins и, в нашем примере, содержит четыре значения pin-sha256 – это и есть отпечатки ключей (значение SHA-256 от публичного ключа, взятое в Base64). Почему их четыре? Потому что на dxdt.ru поддерживается два типа подписей: ECDSA и RSA, соответственно, нужно публиковать отпечатки для каждого из них; кроме того, стандарт требует указания как минимум одного “запасного ключа”, который отсутствует в цепочке валидации – я решил опубликовать по запасному ключу для каждого типа подписи. Итого: четыре отпечатка. Дополнительные отпечатки, очевидно, требуются для того, чтобы можно было поменять ключи без потери доступности сайта.

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

Параметр max-age – определяет (в секундах) время, в течение которого браузер должен сохранять отпечатки. Я, пока что, установил довольно осторожное значение: около трёх суток.

Кроме того, поле Public-Key-Pins позволяет использовать ещё пару параметров: includeSubdomains – это флаг, распространяющий действие отпечатков на поддомены; report-uri – адрес, на который браузер будет передавать сообщения об ошибках. Последний параметр особенно интересен. Он позволяет поднять сервер, который будет получать сообщения от клиентских браузеров, которые натолкнулись на ошибки в работе HPKP – это позволяет обнаруживать атаки “человек посередине”, что называется, в дикой природе. Сообщение содержит детали контекста, в котором возникла ошибка. Эту функцию уже реализует Google Chrome. Естественно, для приёма сообщений нужен отдельный домен. Создание такой точки приёма для dxdt.ru – следующий шаг: нужно выделить сервер и запрограммировать обработчик сообщений.

Addon:

Как получить отпечатки ключей? Достаточно просто, если воспользоваться OpenSSL (я использовал файлы секретных ключей).

Для RSA:

openssl rsa -pubout -in rsa-private.pem -outform DER | openssl dgst -sha256 -binary | openssl enc -base64

Для ECDSA:

openssl ec -pubout -in ec-private.pem -outform DER | openssl dgst -sha256 -binary | openssl enc -base64