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

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

В работе по ссылке – показано, что механизм наследования достаточно силён для того, чтобы покрыть практически всю популяцию, собрав ДНК лишь у небольшой части людей. И речь тут идёт о том, что публичные “анонимизированные” базы позволяют идентифицировать персон, ДНК которых в базе отсутствует, но нашлись родственники разной степени “отдалённости”. Цитата:

“Используя конкретную модель, мы можем предсказать, что база данных с записями о приблизительно 3 млн жителей США европейского происхождения (2% соответствующего взрослого населения), позволяет найти для 99% населения данной этнической принадлежности как минимум одного троюродного родственника, а для 65% – как минимум одного двоюродного”.

Чтобы сопоставить реальных персон записям в базах ДНК, исследователи используют год рождения, примерное место проживания – это позволяет резко улучшить точность. Собственно, задача складывается в чисто комбинаторную, а комбинаторные соображения очень часто помогают убрать всё лишнее и найти реальную структуру, стоящую за данными. Я довольно давно писал на сходную тему, правда, в привязке к “анонимизированным” данным геолокации.

Новая версия TLS 1.3 получила RFC, а именно – RFC 8446 (обратите внимание: TLS 1.0 – RFC 2246, TLS 1.1 – RFC 4346, 1.2 – RFC 5246). Я уже довольно подробно описывал этот новый протокол, который радикально отличается от всех предыдущих версий TLS/SSL. Вот ссылка на подробную статью про TLS 1.3. В блоге Cloudflare – опубликован хороший популярный обзор TLS 1.3 (но он на английском).

TLS 1.3 – это новая версия протокола, вот-вот должен появиться RFC (пока что актуален черновик – draft-28). По адресу https://tls13.1d.pw/ я разместил тестовый сервер, который позволяет попробовать TLS 1.3 на практике, при помощи браузера. Поддержка протокола пока есть далеко не везде. Для сервера я полностью написал стек TLS версии 1.3 на Go, то есть, реализовал всё, что “выше TCP”, так как в стандартной библиотеке поддержки 1.3 нет. (Ну, строго говоря, криптопримитивы использованы библиотечные, а именно – шифры и алгоритмы на эллиптических кривых для протокола Диффи-Хеллмана (DH) и электронной подписи ECDSA.) Это именно тестовый сервер, поэтому он поддерживает не все возможности TLS 1.3, но базовые – поддерживает. В частности, я реализовал две draft-версии: 28 и 23. Draft-28 – должен стать RFC, а 23-й поддерживается распространёнными клиентами. Сервер умеет шифры AES (с GCM) и ChaCha20 (c Poly1305). DH для сеансовых ключей и подпись – только эллиптические (возможно, RSA и “мультипликативный” DH я добавлю позже). Кроме TLS – есть кусочек, поддерживающий HTTP-запрос GET, он позволяет использовать обычный браузер и выводит в текстовом виде подробную информацию о TLS-соединении. Понятно, что для получения этой информации TLS-соединение нужно установить. Версий TLS ниже 1.3 – тестовый сервер не поддерживает (совсем не поддерживает: всё же, это специальный сервер, я просто не стал их реализовывать, так как от 1.3 они отличаются весьма существенно).

Два самых распространённых браузера – Chrome и Firefox – уже умеют TLS 1.3 в своих самых свежих версиях. Я проверил Chrome 68 (версия draft-23 TLS) под Debian и Android 8, FireFox Quantum 62.0b14 (это бета) под Debian, а также Firefox 61 под Android 8: все эти браузеры соединяются с тестовым сервером, а FF 62 даже поддерживает draft-28 (самый свежий вариант). То есть, вы можете попробовать подключиться к тестовому серверу, если у вас актуальная версия браузера. Кроме того, 1.3 умеет утилита s_client из пакета OpenSSL версии 1.1.1-pre8, но это тоже бета-версия, которую нужно самостоятельно собирать. Все прочие типичные инструменты (wget, curl и т.д.) – скорее всего TLS 1.3 пока что не умеют (но планируют быстро добавить поддержку).

Если браузер сумел договориться с сервером, то вы увидите простую текстовую страницу (англ.) с параметрами TLS, в частности, там отображаются сеансовые ключи. Сервер использует полноценный TLS-сертификат от Comodo (с ECDSA), поэтому предупреждений о безопасности барузер показывать не должен. Если соединиться не удалось, то, скорее всего, браузер выведет ту или иную ошибку SSL/TLS. Возможны варианты, когда соединение просто сбрасывается на уровне TCP (например потому, что мой сервер не присылает фиктивное сообщение ChangeCipherSpec, и такие соединения разрывает DPI, но это технические детали, которые, впрочем, очень интересно отследить). Попробуйте: https://tls13.1d.pw.

(Сервер специально использует статический ключ DH и “не слишком случайное” значение поля Random.)

Update: кстати, если вы хорошо знакомы с TLS и интересуетесь всякими занимательными “гиковскими” штуками, то рекомендую внимательно взглянуть на открытый ключ ECDSA сервера tls13.1d.pw – этот ключ входит в состав TLS-сертификата (смотреть нужно в шестнадцатеричной записи).

Update 13/08/2018: добавил передачу сообщения ChangeCipherSpec сервером; в случае TLS 1.3 – это фиктивное сообщение, которое нужно только для того, чтобы “замаскировать” TLS-соединение под предыдущие версии, обеспечивая прохождение через промежуточные узлы с DPI и прочей фильтрацией трафика.

English note: there is a test implementation of TLS 1.3 server (RFC 8846, draft-28,-17) with HTTPS support.

SNI – это Server Name Indication, поле, которое передаёт клиент на начальном этапе установления TLS-соединения. В данном поле указано имя сервера (на уровне приложений), с которым клиент планирует установить соединение. Например, при обращении к dxdt.ru по HTTPS, ваш браузер указывает в SNI строку dxdt.ru. Указание SNI нужно для того, чтобы на стороне сервера по имени различать “виртуальные хосты” (узлы), которые разделяют общий IP-адрес. Например, если у сервера есть несколько наборов TLS-сертификатов и серверных ключей для разных имён, то на основании SNI он может определить, какие сертификаты передавать в данном TLS-соединении. Сейчас, во всех версиях TLS, включая новейшую 1.3, поле SNI передаётся в открытом виде. Это означает, что прослушивающая канал связи третья сторона может определить имя узла, с которым устанавливается соединение, несмотря на то что TLS использует шифрование для защиты от прослушивания.

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

Тем не менее, решения предлагаются. Скорее всего, значение SNI всё же спрячут. Свежий черновик (draft) RFC предлагает использовать для шифрования SNI записи DNS. Точнее, в DNS предполагается публикация открытого серверного ключа, с помощью которого клиент может зашифровать значение SNI. Такая схема позволяет клиенту сгенерировать нужный ключ заранее, сделав запрос в DNS (сопутствующие параметры публикуются там же, в одной TXT-записи), а сервер сможет расшифровать SNI непосредственно на первой итерации установления соединения (сервер знает секретный ключ). Решение весьма логичное, не требует обмена дополнительными сообщениями, кроме запроса-ответа DNS, который может быть выполнен асинхронно. Предполагается, что публикуемый в DNS ключ относится не к одному конкретному ресурсу, а к сервису, обеспечивающему размещение множества ресурсов.

Фактически, представленная в черновике схема стандартизует Domain Fronting: массовые провайдеры хостинга смогут опубликовать свои ключи для шифрования SNI в DNS, клиенты станут использовать эти ключи для доступа ко всем ресурсам, размещённым у провайдера. Удостоверение подлинности ключей – может быть выполнено в рамках DNSSEC. Ну и следует отметить, что ключи для шифрования SNI могут быть переданы не только через DNS.

Опубликована работа, описывающая успешную подмену данных в пакетах DNS, доставляемых через сеть мобильной связи стандарта LTE. DNS посвящена только часть работы, но это самая содержательная часть. Авторы также рассматривают методику построения отпечатков веб-трафика, которую можно применить для определения посещаемых веб-сайтов, и методы частичной идентификации устройств в сети. При этом, применительно к веб-трафику, конфигурация, необходимая для успешной атаки, оказывается слишком далёкой от практики – об этом прямо сказано в статье: работающий в статических лабораторных условиях метод не учитывает реального разнообразия сочетаний технических параметров сети. Идентификация – полностью пассивная, вычисляет требуемые входные данные на основе анализа управляющих сообщений, но позволяет установить лишь промежуточные значения идентификаторов, связанных с оконечным оборудованием.

А вот DNS авторам удаётся подменить полностью, несмотря на то, что LTE считается существенно более защищённой технологией, по сравнению с предыдущими поколениями 2G/3G. Суть атаки состоит в подмене части данных внутри UDP-пакетов, представляющих запрос и ответ DNS. Для этого требуется провести активную атаку типа “человек посередине” (MiTM), то есть, абонентское устройство должно подключиться к подменному узлу, который транслирует пакеты между ним и “подлинной” LTE-сетью. Казалось бы, LTE – современный протокол. Тем не менее, для основной части пользовательских данных в нём не используется аутентификация сообщений, хотя данные и передаются в зашифрованном виде. Данные зашифровываются AES в режиме счётчика (CTR), но, так как целостность не проверяется, пакеты могут быть прозрачно изменены.

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

В режиме шифрования CTR, блочный шифр используется для зашифрования некоторого значения, изменяющегося для каждого следующего блока – это даёт ключевую последовательность (или гамму). Далее вычисляется XOR от блоков открытого текста и соответствующих блоков ключевой последовательности: это прямое побайтовое суммирование. Так как атакующий перехватывает все сообщения, ему известно значение блока шифротекста. Также, из структуры пакетов, известны смещения байтов, содержащих запись IP-адреса и значения этих байтов. Соответственно, атакующий может легко вычислить такую маску, которая при последующем суммировании с ключевым потоком на стороне настоящей сети LTE даст в результате нужные значения байтов записи адреса. Эту маску атакующий записывает в нужный фрагмент зашифрованного пакета. Это типовая атака, очень давно известная для режимов CTR (это, конечно, только подчёркивает странность того факта, что в LTE здесь нет контроля целостности). Единственную небольшую проблему создают контрольные суммы, которые есть и в IP-пакете, и в части, относящейся к UDP. Авторы работы справляются с этой проблемой при помощи модификации значений дополнительных полей пакетов, которые также известны заранее (в частности, поле TTL IP).

Модифицированный пакет с DNS-запросом будет успешно обработан подставным сервером, после чего абонентский смартфон получит подставной ответ, тем самым можно переадресовать HTTP-запросы и запросы других протоколов, при условии, что реализация использует DNS. Это, в частности, актуально для распространённых мессенджеров.

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

p = 2ⁿ – 2ⁿ⁻⁶⁴ + 2⁶⁴(⌊2ⁿ⁻¹³⁰e⌋ + x) – 1

Для чего она нужна и что обозначает?

В новой версии TLS 1.3 зафиксированы практически все криптографические параметры, которые только можно как-то зафиксировать. Так, зафиксированы группы для протокола Диффи-Хеллмана (DH), причём, даже группы для “классического” варианта (“классический” – это который в мультипликативной группе кольца вычетов; а если говорить проще, то тот вариант, который по модулю простого числа, с взятием остатков, а не эллиптический). С наперёд заданными параметрами криптосистем связаны опасения: а вдруг эти параметры специально выбраны с бэкдором? Поэтому существуют методы, позволяющие генерировать параметры некоторым проверяемым и, вместе с тем, “непредсказуемым” способом. Теперь переходим к формуле.

Это формула, по которой генерируются простые числа, задающие группу для DH в TLS. n – требуемая разрядность, e – основание натурального логарифма, x – переменная, принимающая целые положительные значения. То есть, можно сказать, эта формула извлекает из числа e подходящее целое простое число нужной разрядности (подходящее – потому что подходит не всякое, но это детали). Для получения именно простого числа – нужно подбирать значение x (используется минимальное подходящее). Механизм описан в RFC 7919 (но попробуйте “нагуглить” эту формулу).

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

Впрочем, с фиксированными параметрами DH связаны и более простые рассуждения: стойкость DH базируется на сложности дискретного логарифмирования, но для классического варианта и заранее заданной группы (параметра, то есть) известно, что можно предвычислить некоторые алгебраические структуры, которые потом позволят вычислять логарифм быстро. Правда, такие вычисления требуют огромных мощностей и/или затрат времени. Но если вы теоретико-числовая служба специального агентства и заранее знаете, что набор из нескольких групп позволит раскрывать почти весь TLS-трафик, то можно и потратиться. Ключевой момент тут – нужно заранее знать группу, а универсальные методы неизвестны.

На dxdt.ru есть страница с избранными записками. Добавил туда вот эти пять:

• “Ключи на клиенте” и протокол Диффи-Хеллмана
• Скрытое управление пограничными маршрутизаторами
• Обнаружение и извлечение документов с пользовательского компьютера
• Антивирусы и “подмена” сертификатов в браузерах
• Сложности стеганографии

Многие слышали про криптографию на эллиптических кривых. Но эллиптические кривые, которые давно являются мощным инструментом теории чисел, можно успешно применить к решению элементарной (по формулировке) арифметической задачки про бананы, яблоки и ананасы. Текст ниже – несколько сокращённая версия моего перевода ответа Quora.com, который дал Alon Amit (англ.).
Читать полностью

Сейчас сайт снова должен быть доступен из сетей российских провайдеров в штатном режиме. Так как некоторое время назад многочисленные сети (миллионы IP-адресов) попали под блокировку, в том числе, и подсеть с адресами dxdt.ru, пришлось добавить IP-адресов сайту. Это делается при помощи внесения дополнительных A-записей в DNS. Я добавил ещё три адреса, сделав на соответствующих узлах TCP-туннели к основному серверу (сейчас уже вернул единственный адрес, так как блокировки пошли на спад).

Почему это работало. В случае наличия нескольких адресов, браузер, обнаружив недоступность какого-то из них (из-за блокировок у провайдера), должен попробовать установить соединение с другим адресом. В принципе, всё примерно так и выходило, но только не в случае HTTP: потому что для HTTP некоторые провайдеры показывали “заглушку”, сообщающую о том, что сайт заблокирован. Соответственно, браузер полагал, что эта заглушка и есть сайт, и не делал попыток обратиться по другим адресам. Тут нужно учитывать следующий момент: первый GET-запрос, для извлечения основного тела документа, браузер всегда делает только по одному из адресов; это обусловлено тем, что отправлять два одинаковых запроса на разные IP-адреса в ситуации нормальной работы Сети особого смысла нет, это лишь создаст дополнительный трафик и нагрузку. Уже после того, как получен основной код страницы, браузер обращается ко всем доступным IP-адресам веб-узла параллельно, за сопутствующими ресурсами, а именно – за картинками, таблицами стилей и так далее. Но когда провайдер перехватывает запрос и подменяет узел dxdt.ru на свой собственный, браузер получает код этой провайдерской страницы. В итоге, если пользователю с HTTP не повезло, и его браузер обратился именно к заблокированному IP-адресу из имеющихся, то и на сайт браузер уже не попадёт, до повторной попытки загрузки.

А вот с HTTPS ситуация гораздо лучше: пока что не все провайдеры пытаются подменять TLS-узлы, поэтому соответствующие TCP-соединения просто разрываются, а браузер сразу видит, что этот адрес нерабочий и прозрачно переходит к следующему. Вмешательство же провайдера в TLS-соединение при помощи подмены узла – будет приводить к появлению предупреждения браузера. Так как dxdt.ru использует HPKP, это предупреждение во многих браузерах нельзя “подавить”, кликнув что-нибудь вроде кнопки “Всё равно продолжить”. Таким образом, HPKP тоже очень хорошо помогает в подобных случаях. Кстати, Google собирается убрать поддержку HPKP из Chrome, под совершенно надуманным предлогом. Это, в принципе, понятно: корпорация, с некоторых пор, не желает давать в руки пользователям распределённый, независимый от некоторого центра инструмент проверки подлинности сайтов. Впрочем, это другая история.

Итак, сайт dxdt.ru должен быть опять доступен.