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

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

На слуху сейчас пара методов защиты DNS, а также косвенно связываемый с DNS метод защиты доступа, реализующий аутентификацию по имени (TLS). Пара методов, относящихся непосредственно к DNS, это криптографическое расширение самой системы – DNSSEC, а кроме того защита трафика при помощи TLS – DNS-over-TLS (далее – DoT, сюда же относится “надстройка” в виде DNS-over-HTTPS, DoH). При этом часто можно услышать, что TLS, используемый для веба, – то есть, HTTP-over-TLS, – решает вопрос подмены DNS, так как позволяет аутентифицировать веб-узел по имени.

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

Основное отличие TLS, как метода защиты в вебе, для HTTPS, от защиты DNS состоит в том, что для срабатывания TLS в вебе клиент всё же должен подключиться к атакующему, подменному узлу. А это совсем другая поверхность атаки. Например, атакующий узел может “проэксплуатировать” какие-то дефекты клиентской реализации TLS, что отменит требование о наличии легитимного сертификата: в особо продвинутых случаях ни один HTTP-запрос даже не будет отправлен, но клиент окажется взломан, получив код с атакующего узла. DNS, срабатывая раньше, позволяет предотвратить _само_ _подключение_ к подменному узлу по TLS. То есть, эффективная защита DNS предоставляет тут дополнительный рубеж безопасности. Поэтому предположение, что использование TLS с сертификатами в HTTP-over-TLS достаточно для защиты клиента, и поэтому не нужно защищать DNS, так как TLS решит все проблемы выше уровня IP, – ошибочно. (Не будем, впрочем, забывать, что TLS-сертификаты можно получить для IP-адресов тоже, даже в Let’s Encrypt автоматом.)

Но с защитой DNS есть свои проблемы. Вернёмся к паре упомянутых выше методов такой защиты. Первый из них – DNSSEC. Эта технология крайне мало распространена в доменных зонах. Зато DNSSEC касается буквально всех пользователей валидирующих резолверов, так как используется в корневом домене. Всего лишь несколько десятичных цифр позволяют отломить зону верхнего уровня целиком, при этом аварию DNSSEC в большой зоне замечают все и сразу, очередной раз демонстрируя, что про DNS мало кто вообще в курсе, пока эта технология работает, но как только ломается – о DNS узнаёт едва ли не каждый. Второй метод защиты, – DoT/DoH, – распространён существенно больше, поскольку на клиенте встроен прямо в браузеры, но касается только тех сессий, в которых используется. Так вышло потому, что эти технологии тоже принципиально различаются: и по шагам использования, и по уровню применения (почти как HTTP-over-TLS).

DNSSEC методами цифровой подписи обеспечивает аутентификацию данных в DNS. Основная практическая особенность DNSSEC в том, что она позволяет полностью отделить доверие источнику данных от доверия составу данных: не важно, каким образом и от какого узла получены DNS-данные с подписями DNSSEC, главное – чтобы подписи сходились к доверенному ключу. Доверенным, обычно, выступает ключ подписи ключей глобальной корневой зоны.

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

Вспомним теперь, что DoH используется только на “последней DNS-миле”, то есть, от клиента к рекурсивному резолверу. DoT может использоваться и на авторитативных серверах (например, поддерживается NS wikimedia.org и facebook.com), но, всё же, распространена эта технология тоже только на “последней DNS-миле”. Таким образом, DoT/DoH не позволяют проверить подлинность DNS-данных, как их видит резолвер, но позволяют аутентифицировать резолвер и зашифровать данные на “последней DNS-миле”. DoT/DoH скрывают трафик от пассивно прослушивающей канал стороны – обычные DNS-пакеты, напротив, ходят в открытом виде, так как DNSSEC никакого зашифрования не предусматривает. Но “последняя миля” тут очень важна: трафик DNS к резолверу, соответствующий запросу клиента, всё равно ходит в открытом виде (если, конечно, резолвер не использует только DoT в направлении авторитативных серверов, но так сейчас работать DNS не будет на практике). В DNS-запросы могут быть встроены маркеры, которые позволят различать источники этих запросов на промежуточных узлах “за резолвером”.

Интересно, что в DNS, как в систему, давно встроены базовые методы защиты от спуфинга ответов. Встроены они на уровне пакетов и UDP-обмена. Классический элемент пакета – это поле TransactionID, которое содержит 16-битный идентификатор: предполагается, что корректный ответ сервера будет содержать TransactionID, совпадающий с присланным в запросе, и это позволит клиенту (резолверу) отличить настоящий ответ от “подспуфленного”, который присылает узел, не видевший запроса. Второй элемент – номер порта источника, указываемый в UDP-пакете. Работать должно аналогично схеме с TransactionID, но с учётом особенностей транспорта: то есть, ответ на тот же номер порта, который указан в качестве источника (и тут необходимо “передать привет” NAT). Есть и более экзотическая схема, построенная на рандомизации регистра символов имени (DNS Case Randomisation). Эти методы работают где-то между DNSSEC и DNS-over-TLS: сторона, видевшая запрос, всё равно может подделать ответ.

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

Аккаунт на “Хабре” у меня уже больше пятнадцати лет, однако за эти годы я там написал только два комментария (сейчас уже четыре!). Подумал, что, наверное, пора и статью попробовать опубликовать – подготовил, да и опубликовал технический текст про ключи и шифротексты ML-KEM в TLS, с числами и байтами.

Недавно, в заметке про TLS-сертификаты для IP-адресов, я упоминал метод проверки права управления узлом через TLS-ALPN, который может использоваться в рамках ACME (протокол автоматического взаимодействия с Удостоверяющим Центром – УЦ). Надо заметить, это самый экзотический способ проверки из сейчас используемых. Вообще, понятно, что для IP-адресов проверять административные права через DNS – не самый разумный вариант, поскольку DNS надстроена над IP-адресным пространством и проверить не получится. В этом случае даже общепринятое название процесса DCV – Domain Control Validation – не подходит, ведь проверки “управления доменом” тут нет, а есть проверка управления узлом. Поэтому-то даже и обратная зона не сгодится: возможность внесения записей в обратную зону означает, что оператор (предположительно!) управляет соответствующим префиксом, но не обязательно управляет интернет-узлами, попадающими в адресное пространство префикса.

Схема TLS-ALPN работает в типовом варианте “запрос – подтверждение”, но выполняется на самом низком уровне TLS. Логика следующая:
проверяющая сторона, – то есть, сервис УЦ, – устанавливает с проверяемым узлом TLS-соединение, указывая в начальном сообщении (ClientHello) специальное значение в расширении ALPN – это запрос;
проверяемый узел в ответном сообщении TLS (Certificates) отправляет в качестве сигнала специально сконструированный TLS-сертификат, содержащий нужные для подтверждения параметры в расширении SAN (это дополнительные имена и IP-адреса) и в специальном расширении acmeIdentifier.

Сами значения согласуются заранее, в ходе подготовительных шагов ACME.

ALPN – Application-Layer Protocol Negotiation – это штатный инструмент TLS, но в данном случае используется уникальный идентификатор, предназначенный именно для этой схемы: “acme-tls/1”. Использование же TLS-сертификата в роли средства доставки специального сигнала – механизм пусть и причудливый, но всё же иногда используемый. Например, я в своём тестовом сервере TLS передаю сигнальный сертификат, который генерируется каждый раз в ходе установления соединения и содержит сведения об IP-клиента и выбранном способе согласования симметричных ключей. (Но в браузере вы этот сертификат увидеть не сможете, хоть он и всегда есть в сессии.)

Конечно, основной особенностью данного метода является то, что он требует достаточно низкоуровневого взаимодействия с TLS-сервером и срабатывает до того, как запросы вообще доберутся до веб-сервера. Собственно, веб-сервер тут вовсе и не участвует в процессе.

Да, в принципе, используя тот момент, что для TLS-ALPN-подтверждения сертификат нужно сгенерировать заранее, и то, что указание ALPN и имени сервера позволяет воспользоваться программным интерфейсом той или иной TLS-библиотеки, возможно прозрачно подставить сигнальный сертификат в TLS-ответ даже в том случае, когда полного контроля над TLS-сессией нет. Но схема от этого не перестаёт быть низкоуровневой и экзотической.

TLS-cертификаты для IP-адресов, которые собирается выпускать Let’s Encrypt, могут быть полезны и для решения задач внедрения DNS-over-TLS (DoT) на авторитативных серверах DNS. Аутентификационное имя DNS к узлу, поддерживающему DoT, привязать довольно сложно, а вот IP-адрес всегда есть. Другое дело, что DNS уже централизована дважды: через управление содержанием корневой зоны (это архитектурное требование DNS, позволяющее сохранять глобальность) и через управление корневым ключом DNSSEC (это архитектурное требование уже для глобальности DNSSEC, усиливающее позиции корня DNS). Если ещё и транспорт для DNS завести на центральный УЦ, то централизация усилится многократно. Конечно, возможно, это и является целью.

На тестовом сервере tls13.1d.pw сделал некоторые обновления: 1) детализировал вывод шифротекста ML-KEM-768, разбив блок на представления отдельных полиномов; 2) добавил поддержку SecP256r1MLKEM768 – это гибридная криптосистема с постквантовой стойкостью, состоящая из ECDH на кривой P-256 и ML-KEM-768.

Я не так давно писал про статистику соединений с постквантовыми криптосистемами на тестовом сервере, и в той записке обозначил, что SecP256r1MLKEM768 поддерживается сервером, но это оказалось преждевременным, так как в действительности сервер поддерживал ECDH на P-256 только в старом варианте, с Kyber768. А про вариант ECDH с ML-KEM я как-то забыл. Впрочем, на основное утверждение упомянутой записки о том, что с SecP256r1MLKEM768 (идентификатор 0x11EB) на сервер в начале января никто не приходил, этот момент никак не повлиял: понятно, что если никто не пытался подключиться с этой криптосистемой, то и соединения быть не могло, вне зависимости от поддержки сервером.

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

Кстати, забавно, что в SecP256r1MLKEM768 ключи и секреты объединяются в другом порядке, относительно X25519MLKEM768, описанной в том же черновике RFC. То есть, эти гибридные криптосистемы используют объединение значений, соответствующих работе двух криптосистем. Объединение – при помощи простой конкатенации байтов. Например, объединяется запись открытого ключа ECDH (65 байтов) и запись открытого ключа ML-KEM-768 (1184 байта): одни байты приписываются к другим и получается блок в 1249 байтов. Ничего необычного. Но вот для X25519 и ML-KEM, если смотреть слева направо, в сетевом порядке, то сперва идёт ключ ML-KEM, а потом – ключ X25519. Для ECDH и ML-KEM, определяемой в следующем же абзаце черновика, указан другой порядок: сперва параметр ECDH, а потом – ключ ML-KEM. То же самое с общими секретами. Зачем так делать? Загадка. Какая-то “популярная квантовая механика” на пустом месте. (Никакого криптографического смысла в этом нет и быть не может: криптосистемы, составляющие гибрид, работают независимо.)

Шестидневные TLS-сертификаты Let’s Encrypt планирует выпускать и для IP-адресов, что несколько необычно. Тут имеется в виду, что такие сертификаты будут валидными при обращении к узлу без использования DNS-имени, а только по IP-адресу. Такие сертификаты являются редкостью, но выпускались они и раньше – например, сертификат, выпущенный DigiCert 02.01.2025 для сервиса Cloudflare 1.1.1.1, содержит несколько IP-адресов в поле SAN (Subject Alternative Name). Этот сертификат выпущен не на шесть дней, а на срок более года: он действует до 21.01.2026.

Понятно, что DNS для подтверждения управления IP-адресами не подходит. Поэтому проверяется только факт управления узлом под заданным IP-адресом. Let’s Encrypt будет проводить такую проверку по HTTP и через TLS-ALPN (а это довольно экзотический метод, реализующий “прозрачную” проверку на уровне TLS: то есть, на уровне веб-сервера её даже не видно; возможно, я как-нибудь напишу про этот протокол подробнее).

Активный перехват трафика, адресованного некоторому IP, конечно, возможен, – в том числе, через BGP-атаки, – но тогда он же, формально, закрывает и все прочие случаи: например, для DNS-проверки можно перехватывать трафик в направлении авторитативных серверов. Другое дело, что в DNS, обычно, серверов несколько и они даже должны бы находиться в разных автономных системах. Это кроме того, что можно проверять DNSSEC (но это редкость).

Однако сертификаты на IP-адреса позволяют запускать доверенные сервисы, обращение к которым не раскрывает имён уровня приложений. Представьте, что некоторая “точка входа” постоянно мигрирует по IPv6-адресам, автоматически выпуская “короткие” сертификаты с подтверждением через TLS-ALPN – то есть, HTTP там вообще нет. Получается гибкое и скрытное решение. В общем, интересное развитие технологий.

(Я недавно подробно описывал то, как срок действия сертификатов в TLS связан с проблемой компрометации ключей.)

Немного о статусе постквантовой криптографии в TLS. Постквантовые криптосистемы обмена ключами для TLS планируется поддерживать только в TLS 1.3. По крайней мере, так сейчас выглядит тенденция: скорее всего, TLS 1.2 сперва “заморозят”, а потом, достаточно скоро, объявят нерекомендуемым, как уже сделано в RFC 8996 для версий 1.0, 1.1. Обратите внимание, что в RFC прямо сказано: “MUST NOT be used” – в терминах этих документов MUST NOT именно и означает, что строго запрещено использовать, без вариантов. Конечно, если ваше приложение соответствует данному RFC – так-то все спецификации носят рекомендательный характер.

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

Именно стройная логика установления соединения теперь и позволила прозрачно добавить в TLS 1.3 криптосистемы обмена ключами с постквантовой стойкостью. Версия 1.3 полностью несовместима с 1.2, даже на уровне описания процессов, но зато в 1.3 убрано очень много невнятных нагромождений из “дополнений, расширений и уточнений”, которые характерны для 1.2. Конечно, в 1.3 есть свои невнятные моменты – например, трактовка значения “исторических” номеров версий в заголовках TLS-записей, – но, пока что, объём этих недостатков не существенен.

Технически, принести постквантовые криптосистемы можно и в TLS 1.2 – там достаточно механизмов для расширения протокола. Но смысл в поддержке TLS 1.2 можно найти только такой, что сохраняется совместимость со старыми программами и средами, которые невозможно обновить. Однако, если исходить из этого, то не стоит ожидать и добавления реализаций постквантовых криптосистем в эти программы и среды. При этом, TLS 1.3 лучше со всех сторон, – в том числе, в плане программной реализации, – поэтому продолжать тянуть ещё одну версию, за вычетом требований исторической совместимости, несколько странно. Да, можно предположить, что если вдруг в 1.3 обнаружится какой-то удивительный и фатальный архитектурный дефект, то использование 1.2 позволит избежать одномоментного обвала всего и вся. Но на уровне протоколов TLS – это сильно вряд ли, а учитывая архитектурную выверенность TLS 1.3, что-то подобное скорее произойдёт с 1.2. А вот поверить в какие-то дефекты распространённых реализаций – нетрудно. Но, опять же, не факт, что поломается именно 1.3, в котором меньше мест, где можно споткнуться. Поэтому-то развитие, в виде добавления постквантовых криптосистем, и относится только к 1.3.

Достаточно давно сформировалась тенденция к сокращению срока действия TLS-сертификатов для веба. Let’s Encrypt в следующем году обещает шестидневные сертификаты. То есть, TLS-сертификаты, срок действия которых будет около шести суток (ну, плюс какие-то интервалы в несколько часов, видимо). Цитата:

[…] short-lived certificates. Specifically, certificates with a lifetime of six days. This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event. ([…] короткоживущие сертификаты. Точнее, сертификаты со сроком действия шесть дней. Это большое обновление безопасности для TLS-экосистемы, поскольку оно минимизирует время действия уязвимости в случае компрометации ключа.)

Собственно, основная публичная мотивация, стоящая за этим движением – это то, что отзыв сертификатов в TLS для веба и браузеров, фактически, не работает: наладить его так и не удалось. (И с этим – не поспорить.) Ну, понятно, что такой расклад полностью меняет реальность для коммерческих УЦ – от разового выпуска сертификата нужно переходить к предоставлению непрерывного сервиса “обновления” (а в рамках “технологической зависимости” это означает, что нужно реализовывать ACME, который, почему-то, считают “стандартом”).

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

Это нововведение Let’s Encrypt, не сомневайтесь, прямо означает, что браузеры, следом за Chrome/Chromium от Google, постараются оперативно перейти на короткие сертификаты, запретив срок действия дольше месяца (например).

Поскольку браузеры, – в том числе, самый свежий Firefox, – перешли с Kyber768 на ML-KEM, я добавил на свой тестовый сервер TLS поддержку X25519MLKEM768 (не удаляя “гибриды” с Kyber768). Проверить можно при помощи новых версий браузеров Chrome и Firefox.

Кстати, немного занимательных элементов. В процессе развития постквантовой криптографии в TLS уже успели поменять “порядок байтов”. Так, в новых версиях представлений гибридных ключей – разная конкатенация массивов: в “старом” X25519Kyber768, если смотреть в сетевом порядке (так сказать, слева направо, что, конечно, математически неверно), сначала идёт ключ X25519, а потом – Kyber768; в “новом” X25519MLKEM – наоборот, сначала данные ML-KEM, а потом – X25519.

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

Иногда при отладке программ требуется просматривать трафик, защищённый TLS. Распространённый случай – HTTPS. Чтобы просматривать содержание TLS-трафика при помощи анализаторов протоколов (Wireshark) нужны сессионные ключи. В этой записке посмотрим, с примерами кода, как экспортировать эти ключи, если используется типовая библиотека Go crypto/tls.

Принцип довольно простой: при установлении TLS-соединения библиотека будет выводить сеансовые симметричные секреты и сопроводительный параметр (поле Random) в заданный файл, который позже использует Wireshark (или tshark, как в примерах ниже) для раскрытия трафика. Чтобы это заработало в Go, достаточно в структуре конфигурации TLS-клиента (или TLS-сервера) указать (KeyLogWriter) имя интерфейса для записи в файл (writer в терминологии Go), а сам интерфейс предварительно создать и направить вывод в нужный файл. А именно (ниже будет рабочий пример кода; здесь – фрагмент):

SessionKeysFile, err := os.OpenFile("s-keys.txt", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0600)
if err != nil {
[...]
}
[...]
TLSConfig.KeyLogWriter = SessionKeysFile

Так сконфигурированный экземпляр TLS-соединения (в смысле кода Go) будет писать в заданный файл s-keys.txt сведения о ключах, в текстовом формате. Сам формат очень простой, но отличается для TLS 1.3 и других версий (см. ниже). Полный пример работающего кода для TLS-клиента (логика кода экспорта ключей для сервера – не отличается):

package main

import (
	"fmt"
	"net"
	"time"
	"crypto/tls"
	"os"
)

func main(){
	var TLSConfig tls.Config
	SessionKeysFile, err := os.OpenFile("s-keys.txt", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0600)
	if err != nil {
		fmt.Printf("File error: %s\n", err.Error())
		os.Exit(1) 
	}
	hostname := "example.com"

	TLSConfig.KeyLogWriter = SessionKeysFile
	TLSConfig.MinVersion = tls.VersionTLS13
	TLSConfig.MaxVersion = tls.VersionTLS13
	TLSConfig.RootCAs = nil
	TLSConfig.InsecureSkipVerify = true

	timeout := 3 * time.Second
	TCPConn, err := net.DialTimeout("tcp", hostname + ":443", timeout)
	if err != nil {
		fmt.Printf("Connection error: %s\n", err.Error())
		os.Exit(1)
	}

	TCPConn.SetReadDeadline(time.Now().Add(timeout))
	TCPConn.SetWriteDeadline(time.Now().Add(timeout))

	TLSConn := tls.Client(TCPConn, &TLSConfig)

	HTTPGet := "GET / HTTP/1.1\r\nHost: " + 
				hostname + "\r\n" + 
				"Connection: close\r\n" +
				"User-Agent: TLS-keys-dump" + 
				"\r\n\r\n"
				
	_, err = TLSConn.Write([]byte(HTTPGet))
	if err != nil {
		fmt.Printf("Connection (TLS) write error: %s\n", err.Error())
		TLSConn.Close()
		os.Exit(1)
	}
	TLSConn.Close()
	os.Exit(0)
}

Используя привычные многим tcpdump и tshark нетрудно посмотреть, что получилось. В tshark файл с сессионными секретами передаётся при помощи опции tls.keylog_file (в Wireshark – можно загрузить через интерфейс редактирования параметров TLS-парсера). Вызов tshark:

$ tshark -r dump-ens.pcap -o tls.keylog_file:tls-export-keys/s-keys.txt -O tls -S "-----PACKET-----" -x

Здесь: dump-ens.pcap – дамп трафика, записанный tcpdump; s-keys.txt – файл, в который экспортированы TLS-секреты.
Фрагмент результата работы:

Decrypted TLS (83 bytes):
0000  47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a   GET / HTTP/1.1..
0010  48 6f 73 74 3a 20 65 78 61 6d 70 6c 65 2e 63 6f   Host: example.co
0020  6d 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63   m..Connection: c
0030  6c 6f 73 65 0d 0a 55 73 65 72 2d 41 67 65 6e 74   lose..User-Agent
0040  3a 20 54 4c 53 2d 6b 65 79 73 2d 64 75 6d 70 0d   : TLS-keys-dump.
0050  0a 0d 0a

Обратите, кстати, внимание на то, что в TLS 1.3 без секретных ключей сессии не удалось бы посмотреть даже серверные сертификаты. Так что, вообще говоря, для того, чтобы убедится в работоспособности метода, можно было бы даже и не отправлять GET-запрос HTTP, как написано в коде выше: для минимальной проверки в TLS 1.3 достаточно сразу разорвать TLS-соединение, при этом факт успешной записи части сессионных ключей в файл отразится в том, что tshark смог разобрать TLS-сертификаты, присланные сервером. Другое дело, что в TLS 1.3 для зашифрования сертификатов используются другие ключи, не те, что для защиты трафика (см. ниже).

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

CLIENT_HANDSHAKE_TRAFFIC_SECRET [%RANDOM%] [%SECRET%]
SERVER_HANDSHAKE_TRAFFIC_SECRET [%RANDOM%] [%SECRET%]
CLIENT_TRAFFIC_SECRET_0 [%RANDOM%] [%SECRET%]
SERVER_TRAFFIC_SECRET_0 [%RANDOM%] [%SECRET%]

Чтобы не перегружать текст шестнадцатеричными цифрами я заменил поля, содержащие соответствующие данные, на понятные имена: [%RANDOM%] и [%SECRET%]. В исходном файле, очевидно, на месте этих обозначений будут длинные наборы шестнадцатеричных цифр.

В поле с именем [%RANDOM%] записывается значение из поля Random начального сообщения ClientHello. Это может показаться загадочным, если вы не сталкивались с TLS ранее, однако тут данное значение нужно лишь для того, чтобы анализатор протокола мог быстро сопоставить конкретный секрет и конкретную TLS-сессию в записанном трафике: то есть, в данном случае, это всего лишь метка. Сам секрет, позволяющий получить ключи для шифров, указывается в поле [%SECRET%]. (Ключи вычисляются на основе данного секрета при помощи соответствующей функции HKDF.)

В файле указаны клиентские и серверные секреты для разных этапов соединения TLS 1.3. CLIENT(SERVER)_HANDSHAKE_TRAFFIC_SECRET – это ключи для защиты начальных сообщений. CLIENT(SERVER)_TRAFFIC_SECRET_0 – это ключи первого поколения для защиты трафика. В TLS 1.3 возможно обновление ключей в рамках сессии, то есть, могли бы быть и TRAFFIC_SECRET_n следующих поколений, но это тема для другой записки. Формат файла подразумевает и другие поля, которые тоже тут не рассматриваются – все они устроены так же, но сдержат секреты других типов, которые могут появиться в ходе соединения TLS 1.3, так что анализаторы трафика должны обрабатывать их автоматически.

Для TLS 1.2 файл с экспортируемыми секретами, генерируемый библиотекой Go, будет будет использовать другой формат:

CLIENT_RANDOM [%RANDOM%] [%SECRET%]

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

***

Некоторые другие записки по этой же теме:

TLS для DevOps
Секретные ключи в трафике и симметричные шифры
TLS в виртуальных машинах и извлечение ключей хостингом

Технические детали устройства TLS – можно узнать в техническом описании.

Использование имеющихся сейчас посквантовых криптосистем в TLS существенно увеличивает объём передаваемых данных. Например, ключ Kyber768, используемый в первом же сообщении (ClientHello), требует более килобайта (1184 байта). При этом, в TLS 1.3 есть штатная возможность передать несколько ключей для разных криптосистем в одном сообщении ClientHello, чтобы сервер выбрал подходящее. Эта возможность постоянно используется на практике.

Например, клиент может сразу передать ключи X25519 (32 байта) и P-256 (32+32 == 64 байта). То есть, две криптосистемы – и лишь 96 байтов расходуется на запись ключей (небольшое количество дополнительных байтов нужно для записи тех структур, в которых передаются ключи, но это можно не учитывать). Если передавать ключи двух постквантовых криптосистем, – скажем, с теми же Kyber768 и стандартизованным вариантом ML-KEM, – то получается уже больше двух килобайт. Это много, но если регулярно переходить от одной поствкантовой криптосистемы к другой, то становится необходимым, рутинным элементом TLS-соединений. Заметьте, что сам перечень поддерживаемых клиентом криптосистем для обмена сессионными секретами передаётся в TLS отдельно. Обычно, в этом перечне указано значительно больше криптосистем, чем передано ключей. Так, браузер может передавать семь поддерживаемых вариантов и ключи только для трёх из них (так сейчас делает Firefox). Чтобы сервер мог выбрать криптосистему, ключи от которой отсутствуют в ClientHello, в TLS 1.3 предусмотрен механизм повторного согласования – HelloRetryRequest: сервер, в этом случае, запрашивает повторное ClientHello, где будет только ключ той криптосистемы, которая выбрана (это всё можно самостоятельно увидеть на тестовом сервере TLS 1.3 при помощи современного браузера).

Подобный перебор с постквантовыми криптосистемами ещё больше увеличивает трафик, поэтому уже рассматриваются варианты того, как бы данный момент переложить на DNS. Так, в сообщении Google про ML-KEM в браузере Chrome, на которое я недавно ссылался, упоминается соответствующий черновик RFC – там предлагается публиковать в DNS сведения о предпочитаемых криптосистемах для обмена сеансовыми ключами в TLS. Конечно, тут нужно учитывать возможную защиту DNS-ответов от подмены, то есть, всё это тянет за собой не только и не столько DNSSEC (которая сама не имеет пока что ничего “постквантового”), как DNS-over-TLS/DNS-over-HTTPS.

Развитие постквантового TLS очень бурное. Впрочем, пока что не совсем понятно, для чего вообще такой рост объёмов данных. Сама по себе “постквантовая стойкость” тут ничего не объясняет, как и популярные описания в стиле “зашифруй заранее, пока нет квантового компьютера”. Однако вот уже и DNS охвачена дополнением записей. С одной стороны, размещение предварительных сведений о настройках TLS в DNS выглядит более чем разумно: запрос в систему всё равно необходим для получения IP-адреса; с другой стороны – данное направление развития как-то быстро сводится к надстраиванию новых и новых, всё больших и больших “дополнений”. (Надстраивание происходит в ускоряющемся темпе: не успели год назад внедрить в браузеры Kyber, как его уже переименовали в ML-KEM и переделали.) Эти “дополнения” вытесняют привычную работу с DNS, заменяя её на другой процесс, который следует называть “обнаружением сервисов” (Service Discovery) – дело в том, что с появлением ECH даже и IP-адреса будут извлекаться из доступной сети по-другому.