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

(Это дополненная и скорректированная версия статьи, которую я некоторое время назад публиковал на “Хабре”.)

Данные в запросах и ответах классической DNS никак не защищены, передаются в открытом виде. DNS-over-TLS (DoT, RFC 7858) предоставляет один из инструментов защиты информации, а именно: защиту DNS-запросов и DNS-ответов от прослушивания на промежуточных узлах.

DoT использует TLS для зашифрования DNS-транзакций, передаваемых между узлами, но не защищает сами DNS-данные. Под “DNS-данными” тут подразумевается состав ответов и запросов DNS: имена и записи. То есть, если ваш локальный компьютер использует DoT для работы с DNS-сервером, то передаваемые DNS-данные не видны “на транзите” (как объясняется ниже, сам факт обмена DNS-данными обычно всё равно виден) и нельзя простым способом узнать, для какого узла и какие DNS-запросы направлялись. Однако, если DNS-сервер, к которому запросы отправлялись с защитой DoT, возвращает неверные, искажённые DNS-данные, – например, подставляет собственный IP-адрес для, условно, example.com, – то DoT ничего с этим поделать не может – тут уже нужно использовать DNSSEC.

На всякий случай, замечу: DoT – это технология, которая никак не связана с DNS-over-HTTPS (DoH). Архитектура DoT довольно логичная: TLS здесь используется в качестве инструмента создания защищённого “сокета” между DNS-клиентом и DNS-сервером. Через “сокет” передаются те же DNS-запросы/DNS-ответы, как они передавались бы на уровне обычного UDP или TCP. То есть “сокет” с TLS тут нужно считать туннелем, работа которого прозрачна для уровня DNS. Естественно, чтобы использовать DoT в таком прозрачном режиме, нужна поддержка TLS и на клиенте, и на сервере. Однако, поскольку спецификация отводит TLS обособленный уровень (в отличие от DoH), ничто не мешает поднять TLS-соединение между узлами какими-то другим способом, установив тем самым туннель, а запросы/ответы от неподдерживающих TLS клиентов/серверов перенаправлять без изменений через этот туннель.

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

Типовой сценарий работы DNS это так называемый рекурсивный опрос, в котором специальный DNS-сервер (резолвер) производит обход других DNS-серверов (которые называются “авторитативными”), следуя по веткам дерева делегирования с целью поиска данных, соответствующих некоторому ключу. Хрестоматийный пример: в качестве ключа выступает имя хоста (example.com), а целевыми данными является IP-адрес (значение адресной A-записи), то есть, “хотим найти IP-адрес для имени сервера”. DNS правильно рассматривать именно как специальную распределённую базу данных и сервис поиска в этой базе данных. Собственно, сама аббревиатура DNS может расшифровываться двумя способами: Domain Name System и Domain Name Service. DoT – относится к транспорту для сервиса поиска и позволяет защитить трафик каждого DNS-запроса на каждом отрезке. (А криптографическая система на уровне базы данных DNS – это как раз DNSSEC, но DNSSEC не зашифровывает данные.)

Рекурсивный DNS-резолвер, если подходящий ответ отсутствует в кеше, обращается к разным авторитативным серверам Интернета по некоторому довольно сложному алгоритму и, при штатной работе системы, либо получает от сервера нужный ответ о целевом имени, либо получает так называемый делегирующий ответ, который содержит имена других авторитативных серверов и позволяет резолверу продолжить поиск, обращаясь уже к каким-то из этих серверов (откуда и появляется “рекурсия” в названии процесса). При этом рекурсивный резолвер обычно находится за пределами “локальной машины”. В качестве рекурсивного резолвера может выступать сервер провайдера интернет-доступа или публичный сервис типа Google Public DNS 8.8.8.8. На локальной машине DNS-запросы обрабатывает более простая программа – stub-резолвер, который только перенаправляет запросы рекурсивному резолверу (иногда его ещё называют “рекурсор”) и принимает от него ответы. DoT может использоваться на любом участке работы DNS: не только на “последней миле”, то есть на отрезке от локального stub-резолвера к рекурсивному резолверу, но и между авторитативными серверами. Кстати, эта “последняя миля” в современных браузерах как раз часто защищена при помощи DNS-over-HTTPS.

Итак, общая логика работы DoT следующая:

1) произвольный DNS-клиент, если он поддерживает TLS, устанавливает TLS-соединение, подключившись по TCP к DNS-серверу (для UDP есть отдельный вариант – DNS-over-DTLS, здесь можно считать, что он работает так же, как и DoT);
2) DNS-клиент может провести аутентификацию сервера различными способами (см. ниже);
3) если TLS-соединение установлено, то DNS-клиент переходит к отправке DNS-запроса обычным способом, но уже через TLS-соединение;
4) ответ DNS-сервера доставляется в рамках того же TLS-соединения; при этом формат DNS-ответа и прочие свойства – не изменяются, если сравнивать с работой DNS непосредственно по UDP или TCP, без TLS-туннеля (см. ниже);
5) TLS-соединение закрывается, если клиент не планирует использовать его далее.

Для DoT выделен номер порта 853 (классический номер порта DNS – 53). Поэтому клиенты могут сразу пробовать использовать DoT, подключаясь по TCP на номере порта 853. Так как DoT – универсальная спецификация, то такое подключение можно устанавливать и к авторитативным серверам. Но сейчас поддержка DoT на авторитативных серверах является большой редкостью. Тем не менее, DoT поддерживают, например, серверы DNS-зон facebook.com и wikimedia.org.

Практика

Воспользуемся утилитой dig из пакета BIND и посмотрим, как DoT работает вживую на авторитативных серверах. В качестве источника примеров используем зону wikimedia.org, авторитативные серверы имён которой поддерживают DoT.

Утилита dig – это один из типовых инструментов из области DNS. В более или менее современной версии dig умеет в DoT сразу из коробки: нужно просто указывать опцию +tls при вызове. Я здесь использую версию 9.18.33-1 под Raspberry Pi OS (Debian 12).

Сначала определим, на какие серверы делегирована зона wikimedia.org (пока что без DoT), это делается запросом NS-записей (-t NS):

$ dig -t NS +short wikimedia.org
ns1.wikimedia.org.
ns2.wikimedia.org.
ns0.wikimedia.org.

(+short здесь – это краткий формат вывода.)

Наша цель – отправить запрос AAAA-записи (IPv6-адрес) через DoT и получить ответ, посмотрев, с помощью tshark, что происходит в трафике. Кроме того, мы извлечём серверный TLS-сертификат с авторитативного сервера и глянем, что там, в сертификате, написано. Будем использовать авторитативный сервер ns1.wikimedia.org. Однако сначала определим его IPv4-адрес, чтобы DNS-запросы отправлять непосредственно серверу.

$ dig -t A +short ns1.wikimedia.org.
208.80.153.231

Запросили A-запись – получили IPv4-адрес в ответ. Теперь включаем DoT (и тут вообще будет опций побольше, но все они объяснены ниже):

$  dig -t AAAA @208.80.153.231 +tls +nocookie +norec wikimedia.org

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> -t AAAA @208.80.153.231 +tls +nocookie +norec wikimedia.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44438
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; TCP KEEPALIVE: 157.0 secs
; PAD: (388 bytes)
;; QUESTION SECTION:
;wikimedia.org.			IN	AAAA

;; ANSWER SECTION:
wikimedia.org.		300	IN	AAAA	2a02:ec80:300:ed1a::1

;; Query time: 300 msec
;; SERVER: 208.80.153.231#853(208.80.153.231) (TLS)
;; WHEN: Sun Mar 16 18:18:01 MSK 2025
;; MSG SIZE  rcvd: 468

(Опции: +tls - используем DoT, +nocookie - без куки-меток, чтобы не перегружать вывод (DNS-куки не относятся к DoT и тут не рассматриваются: про них планирую отдельную записку опубликовать), +norec - не устанавливаем флаг рекурсии.)

Здесь уже в нижнем информационном блоке видно, что запрос и ответ передавались с использованием TLS, через TCP-соединение на номере порта 853. То есть, это DoT.
Дополнительно подтвердить, что трафик ходил через TLS, можно при помощи tshark, посмотрев в дамп, записанный tcpdump (это два основных инструмента).

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

# tcpdump -i eth0 -w pcap-dns.pcap

Парсинг дампа при помощи tshark:

$ tshark -r pcap-dns.pcap -o tls.keylog_file:keylog.log -O tls,dns -S "-----PACKET-----" -x

Здесь: -r - входной PCAP-файл; -o tls.keylog_file:keylog.log - это импорт сессионных ключей TLS, они потребуются для раскрытия DNS-трафика (про способ экспорта кратко рассказано ниже); -O tls,dns - перечень протоколов для парсера; -S "..." - разделитель "пакетов" в распечатке дампа, можно использовать любую удобную строку; -x - выводить hex-дамп тоже.

В распечатке дампа находим примерно следующее:

Internet Protocol Version 4, Src: 192.168.1.13, Dst: 208.80.153.231
Transmission Control Protocol, Src Port: 36461, Dst Port: 853, Seq: 1, Ack: 1, Len: 303
Transport Layer Security
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 298
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 294
            Version: TLS 1.2 (0x0303)

Это часть сообщения ClientHello, направленного утилитой dig авторитативному DNS-серверу. Соответствующее серверное сообщение ServerHello, которое можно найти в дампе, вместе с возможностью расшифровывать трафик, означает, что узлы успешно установили соединение TLS 1.3. Внутри TLS-соединения передан DNS-запрос и получен DNS-ответ.

Чтобы посмотреть прикладной трафик внутри TLS, нужно экспортировать сессионные ключи - то есть, симметричные секреты, которые стороны использовали для зашифрования трафика. Конкретный способ экспорта зависит от параметров сборки dig и системного окружения, но обычно достаточно установить переменную окружения SSLKEYLOGFILE, чтобы dig, при использовании TLS, выводила ключи в файл или в STDERR (откуда их можно точно так же скопировать). Механика экспорта TLS-ключей не относится к теме данной статьи, поэтому детали остаются за скобками. А вот выдачу tshark для расшифрованного DNS-трафика - посмотрим. Запрос:

Transport Layer Security
    TLSv1.3 Record Layer: Application Data Protocol: Domain Name System
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 61
        [Content Type: Application Data (23)]
        Encrypted Application Data: [...]
        [Application Data Protocol: Domain Name System]
Domain Name System (query)
    Length: 42
    Transaction ID: 0xad96
    Flags: 0x0020 Standard query
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..1. .... = AD bit: Set
        .... .... ...0 .... = Non-authenticated data: Unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        wikimedia.org: type AAAA, class IN
            Name: wikimedia.org
            [Name Length: 13]
            [Label Count: 2]
            Type: AAAA (IPv6 Address) (28)
            Class: IN (0x0001)
[...]

Здесь и далее часть данных (опции EDNS и пр.) удалена, чтобы не слишком растягивать распечатку. В блоке Flags можно видеть параметры запроса, как его сформировала утилита dig. А в блоке Queries (сам запрос) - имя wikimedia.org. и состав запроса IN AAAA. Обратите внимание на поле [Application Data Protocol: Domain Name System]. Вообще, то, что TLS-сессия используется для DoT, видно не только по номеру порта, но и по идентификатору протокола уровня приложений, который dig передаёт в составе начального TLS-сообщения ClientHello. Выглядит это вот так:

Extension: application_layer_protocol_negotiation (len=6)
  Type: application_layer_protocol_negotiation (16)
   Length: 6
    ALPN Extension Length: 4
    ALPN Protocol
     ALPN string length: 3
     ALPN Next Protocol: dot

ALPN - это Application Layer Protocol Negotiation, расширение ClientHello, которое позволяет сразу сообщить серверу, какой именно прикладной протокол будет использован поверх этого соединения. Для DoT зарезервирован идентификатор 0x646F74 (то есть, строка "dot" в ASCII). Расширение передаётся в открытом виде, поэтому системе, инспектирующей трафик, нетрудно классифицировать TLS-сессию как сессию DNS: номер порта и идентификатор протокола - этого вполне достаточно. Понятно, что ни TLS, ни DoT и не ставят своей целью сокрытие факта соединения.

Просматривая выдачу tshark далее, находим DNS-ответ:

Transport Layer Security
    TLSv1.3 Record Layer: Application Data Protocol: Domain Name System
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 487
        [Content Type: Application Data (23)]
        Encrypted Application Data: [...]
        [Application Data Protocol: Domain Name System]
Domain Name System (response)
    Length: 468
    Transaction ID: 0xad96
    Flags: 0x8400 Standard query response, No error
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 1
    Queries
        wikimedia.org: type AAAA, class IN
            Name: wikimedia.org
            [Name Length: 13]
            [Label Count: 2]
            Type: AAAA (IPv6 Address) (28)
            Class: IN (0x0001)
    Answers
        wikimedia.org: type AAAA, class IN, addr 2a02:ec80:300:ed1a::1
            Name: wikimedia.org
            Type: AAAA (IPv6 Address) (28)
            Class: IN (0x0001)
            Time to live: 300 (5 minutes)
            Data length: 16
            AAAA Address: 2a02:ec80:300:ed1a::1
    Additional records
        : type OPT
            Name: 
            Type: OPT (41)
[...]
            Option: EDNS TCP Keepalive
                Option Code: EDNS TCP Keepalive (11)
                Option Length: 2
                Option Data: 0622
                Timeout: 1570
            Option: PADDING
                Option Code: PADDING (12)
                Option Length: 388
                Option Data: 00…
                Padding: 00…

Это исходник DNS-ответа, который был отображён dig (см. распечатку выше). Обратите внимание на секцию "опций", вот её копия из выдачи dig:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; TCP KEEPALIVE: 157.0 secs
; PAD: (388 bytes)

Здесь мы, например, без труда видим, что параметр TCP Keepalive имеет значение 157 секунд, как и в распечатке tshark, а дополнение (padding) совпадает по длине (388 октетов). Как нетрудно догадаться по названию, TCP Keepalive содержит указание на интервал времени, в течение которого сервер (в данном случае) готов поддерживать контекст TCP-соединения, чтобы клиент мог реализовать конвейеризацию запросов. К DoT это относится весьма косвенно, но зато служит прекрасным примером реальной сложности современных DNS-протоколов (про Keepalive в DNS тоже можно написать отдельную статью, как ни странно).

А вот дополнение (padding) к DoT относится в большей степени, чем Keepalive, хоть и так же находится за пределами конкретно DoT. Идея использования дополнения здесь в том, чтобы можно было изменять длину блоков данных, содержащих DNS-транзакции, не влияя на сами транзакции. Если длину блоков выравнивать, то это позволяет сделать семантически разные блоки неразличимыми по длине. Что, кстати, особенно важно, если блоки зашифрованы. Проще говоря, наблюдая трафик, состоящий из разных по длине блоков данных, где длина определяется форматом, можно выстроить корреляцию с конкретными DNS-запросами и ответами по порядку их следования. Ведь параметры известны: длина доменного имени, длина "флагов" и заголовков, количество DNS-записей в ответах и т.д. Это позволит сделать предположения о составе наблюдаемого трафика, даже без раскрытия самого его содержания. Если же вы наблюдаете только ровный конвейер блоков одинаковой длины, в стиле "запрос-ответ, всё в одинаковых коробках", то извлечь дополнительную информацию гораздо сложнее. Естественно, можно при помощи дополнения варьировать длину и так, чтобы, напротив, блоки не были одинаковыми по количеству байтов. Заметьте, что аналогичный механизм выравнивания длины записей с помощью дополнения есть и в TLS 1.3.

TLS-сессия использует серверный сертификат. Для авторитативного сервера ns1.wikimedia.org. TLS-сертификат можно получить из дампа трафика (но, так как там TLS 1.3, придётся расшифровать отдельно), а можно воспользоваться утилитой s_client из OpenSSL: TLS в DoT точно такой же, как и в других случаях, так что s_client сработает прекрасно, нужно лишь подключиться по номеру порта 853, вот так:

$ openssl s_client -connect 208.80.153.231:853

Cертификаты в TLS нужны для аутентификации узлов, то есть для установления подлинности этих узлов. Однако в DoT с сертификатами связаны свои особенности.

Во-первых, спецификация не указывает методов аутентификации, которые обязательно должны использоваться. Основное предназначение TLS-сертификата в том, чтобы привязать открытый ключ сервера к сетевому илмени или адресу. Однако сам TLS-сертификат далеко не всегда полезен для DNS: например, можно ли требовать, чтобы имя авторитативного сервера соответствовало имени в сертификате (как это делается для веба)? В DNS сложно строго сопоставить имена серверов: конкретный контекст DNS-запроса никакого имени сервера не предусматривает - запрос отправляется по IP-адресу. Да, можно наследовать имя из предыдущих запросов и ответов, но получится не самый строгий результат. Поэтому имя из сертификата можно использовать, а можно и игнорировать. Зато TLS-сертификаты для IP-адресов подошли бы неплохо.

Технически, ничто не мешает выпустить сертфикат для IP-адреса. Если говорить про имеющиеся "хорошо известные УЦ", то сертификаты для IP-адресов пока что выпускают неохотно, так как есть трудности с надёжной проверкой права управления адресом, а также с сопровождением. Впрочем, Let's Encrypt обещают довольно скоро сделать автоматические короткоживущие TLS-сертификаты на IP-адреса для всех, используя механизм подтверждения управления адресом чисто по TLS. Это должно позволить в прозрачном режиме привязать ACME-проверку к DoT, не поднимая ненужного, в данном случае, веб-сервера.

Во-вторых, в DoT можно применять дополнительные методы аутентификации, которые не связаны с привычной по вебу инфраструктурой УЦ: например, проверять отпечаток серверного ключа подписи, а не сверять подписи в сертификатах.

В-третьих, DoT использует "приспособительный" подход и к аутентификации, и к TLS в целом. Это то, что в англоязычной традиции называется Opportunistic Security - "если удалось, то обязательно будем аутентифицировать и зашифровывать, а если нет - тогда ладно".

Может показаться, что если серверный сертификат не проверять, то от TLS для DNS нет никакого толку: промежуточный узел может перехватить соединение и подставить свой, произвольный сертификат, подходящий по формату. Однако в случае DoT схема, как минимум, всегда защищает от пассивного прослушивания трафика. Пассивное прослушивание реализовать гораздо проще, чем активный перехват, а защита от утечек через "пассивные" каналы и является основной для DoT. Тем более, если речь идёт о работе с авторитативными DNS-серверами. Защита же от активной атаки может быть реализована на "последней миле", где клиенту, обычно, заранее известны некоторые данные о сервере: имя, ключ и так далее.

Кстати, посмотрим на имена и на интервал валидности сертификата, который вернул сервер ns1.wikimedia.org.:

        Serial Number:
            05:f7:71:aa:08:8e:32:88:0a:71:9c:2d:f3:98:17:e1:d6:aa
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = E5
        Validity
            Not Before: Mar 16 05:02:56 2025 GMT
            Not After : Jun 14 05:02:55 2025 GMT
        Subject: CN = ns0.wikimedia.org

[...]
            X509v3 Subject Alternative Name: 
                DNS:ns0.wikimedia.org, DNS:ns1.wikimedia.org, DNS:ns2.wikimedia.org

Это сертификат, выпущенный Let's Encrypt. Subject пропускаем, смотрим в Subject Alternative Name, где указаны все три имени для трёх авторитативных серверов зоны wikimedia.org., которые мы нашли в самом начале этого экскурса в DoT силами dig.

DoT уже поддерживается основными программными пакетами авторитативных серверов и рекурсивных резолверов. Например, BIND и Unbound. Так что протокол можно внедрять не только на "последней миле", но и на авторитативных серверах, защищая трафик резолверов к этим серверам (и обратно).

Подведём итог. DoT, используя TLS, защищает данные от пассивного прослушивания третьей стороной. Если клиент применяет тот или иной метод аутентификации сервера, то DoT может защитить от активного перехвата и подмены данных. Но всё это работает только на том отрезке, где применяется DoT, а защита TLS не распространяется на сам состав DNS-данных. Чтобы защитить содержательную часть DNS, необходимо использовать DNSSEC, а эту технологию тоже можно изучать при помощи dig на практических DNS-зонах.

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

О чём тут идёт речь? Существуют протоколы обмена командами и данным, в которых использование TLS встроено в схему протокола. То есть, на верхнем логическом уровне, не сам обмен протокола полностью и прозрачно завернут в TLS (как HTTP в HTTPS, скажем), а TLS можно включить, при наличии возможности, уже в контексте самого протокола – пример: SMTP + STARTTLS. То есть, сеанс в рамках атакуемого протокола обязательно начинается в открытом и незащищённом варианте. Это позволяет атакующему подменить начальные сообщения той или иной стороны, а потом переключить трафик на использование TLS: либо штатными средствами протокола, либо – перенаправив трафик на другой номер порта. Атакующий при этом должен активно перехватывать сетевое соединение, подменять пакеты и прозрачно перенаправлять трафик на разные номера портов. (В исходной публикации, для одного из сценариев, ещё и требуют выполнения атакующей стороной произвольного кода в контексте веб-страницы внутри браузера.)

Так, механизм STARTTLS для SMTP – тут сервер может предложить поддержку TLS в самом начале SMTP-сессии, а клиент, если он поддерживает TLS, может тут же начать переход на защищённое соединение, просигнализировав об этом серверу. Если переход на TLS произошёл, то SMTP-сессия начинается, фактически, заново – пусть и в том же сокете, но уже внутри TLS. Но для SMTP есть и вариант с прямым TLS-подключением, то есть, сразу по TLS на другом выделенном номере порта (например, 587, а не 25). Для осуществления атаки требуется, чтобы на сервере были доступны оба способа подключения – смысл и состоит в “перекидывании” сессии между открытым соединением и подставным TLS-соединением.

Атака Opossum для SMTP предлагает атакующему возможность обмануть клиентскую программу, которая пытается подключиться с использованием STARTTLS: атакующий перехватывает соединение этой программы и отвечает вместо сервера, отправляя собственное серверное SMTP-приветствие и опцию, указывающую на STARTTLS; далее, как только клиентская программа начнёт инициировать TLS-соединение, атакующий перенаправляет начальное TLS-сообщение клиента на выделенный для TLS номер порта легитимного сервера; сервер считает, что это просто прямое подключение TLS и обрабатывает его обычным образом. Получается, что клиент прочитал подставное SMTP-приветствие и подставной список SMTP-опций, а потом начал SMTP-сессию через TLS, что для сервера выглядит обычной новой сессией. Таким образом, контекст на сервере как бы отличается от контекста на клиенте. Насколько это критично с практической точки зрения, особенно, на фоне того, что атакующий мог вообще скрыть поддержку TLS сервером, – отдельный вопрос. Но никакой атаки на TLS тут нет, TLS сработал так, как и планировалось, однако шаги штатного протокола на стороне клиента и на стороне сервера теперь не синхронизированы, из-за вмешательства атакующего – запросы и ответы переставлены на полуход. В публикации Opossum это, что логично, так и называется: “десинхронизация прикладного уровня”.

(Иллюстрация из исходной работы.)

Как ни странно, но TLS в “приспособительном” режиме возможен, – в теории, – и для HTTP. Этот вариант, впрочем, практически не встречается на веб-серверах: смысл для HTTP – тёмен, а настраивать нужно отдельно. Для случая HTTP последовательность данной атаки другая: атакующий модифицирует запросы, ответы и задерживает TLS-трафик так, что внутри TLS-сеанса оказывается ответ сервера не на легитимный запрос клиента, а на предыдущий запрос, поступивший к серверу от атакующего в открытом виде. TLS-опять же, атака не касается. Но, как и отмечено в исходной работе, все перечисленные атаки возможны потому, что TLS не предоставляет способа аутентифицировать состояние внешнего протокола на стороне сервера и клиента, а аутентифицирует только имена и адреса. Это так. Однако подобная расширенная аутентификация и не входит в модель TLS: несмотря на наличие расширений типа ALPN, TLS работает только на своём уровне. (Кстати, на ALPN описание атаки Opossum как раз ссылается: с ALPN связана вспомогательная часть и предыдущая атака по теме.)

Let’s Encrypt сообщают, что выпустили первый TLS-сертификат, валидный для IP-адреса. Это сертификат сроком валидности шесть суток, там пустое поле Subject (это важно, если вы всё ещё проверяете сертификаты по Subject), отсутствует ссылка на OCSP, но всё ещё есть ссылка на CRL. IPv6-адрес указан в Subject Alternative Name, вместе с несколькими доменными именами. Часть указанных имён, кстати, имтируют IPv6-адрес, поэтому они аж восьмого уровня. Вообще, максимальная допустимая “глубина” DNS-имён в Let’s Encrypt – десятый уровень.

Провайдер Timeweb, как я заметил, включил поддержку DNS over TLS на двух (как минимум) из своих массовых авторитативных серверов имён (NS): ns2.timeweb.ru., ns4.timeweb.org. Это означает, что резолверы могут использовать TLS при подключении к этим серверам, что автоматом делает DNS over TLS (DoT) довольно распространённой в Рунете технологией, если считать по зонам, так как упомянутые NS использует больше двух с половиной сотен тысяч DNS-зон в .RU.

DoT полезно внедрять на авторитативных серверах. Это защищает трафик резолвера при рекурсивном опросе. Подробно про DoT я недавно писал на “Хабре”.

Скриншот отчёта сервиса проверки настроек DNS:

Хорошо известный удостоверяющий центр SSL.com выпускал TLS-сертификаты для доменов без проверки права управления. Как пишут, статус “подтверждённого имени” получал всякий домен, на произвольный почтовый адрес в котором пользователь смог получить код подтверждения для любого другого домена. То есть, можно было разместить заказ на TLS-сертификат для example.com, выбрать способ подтверждения с отправкой кода по адресу email, указанному в TXT-записи (и такое бывает), – например, akhmet@test.ru, – подтвердить получение кода, и доменное имя из состава адреса, – то есть, test.ru, – тоже получало статус прошедшего проверку права управления.

Очередное подтверждение того, что проверка права управления (DCV) должна проводиться перед выпуском каждого сертификата, для всех имён, указываемых позже в сертификате, и только для этих имён, но строго после получения соответствующего заказа (и процесс подтверждения должен быть привязан к конкретному заказу и к конкретному ключу из заказа). И, конечно, никаких проверок по email для TLS-сертификатов.

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

Скопирую сюда своё сообщение с “Хабра”:

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки – шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS – есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз – для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

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

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

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

Можно ли “смешать” TLS-сертификаты для IP-адресов и для хостнеймов? Например, если говорить о TLS для HTTPS, то тут используются и адреса, и имена: поиск сайта, обычно, происходит по имени хоста (по доменному имени), но само соединение устанавливается по IP-адресу. Соответственно, TLS-клиент, – пусть это будет браузер, – на момент отправки первого TLS-сообщения серверу знает доменное имя и IP-адрес, который сам браузер поставил в соответствие этому имени (в процессе обнаружения адреса использовалась DNS, это понятно). Обычно, чтобы признать сертификат валидным, браузер ожидает, что в TLS-сертификате указано имя, соответствующее ожидаемому имени хоста – это может быть одно из нескольких имён в сертификате, может быть результат “раскрытия” wildcard-имени (“со звёздочкой”).

Технически, в TLS-сертификате, вместе с именами хостов, можно указать и IP-адреса, форматом допускается. За примерами не нужно далеко ходить – сертификат на веб-сервере dns.google содержит и DNS-имена, и IP-адреса:

X509v3 Subject Alternative Name: 
 DNS:dns.google, DNS:dns.google.com, DNS:*.dns.google.com,
 DNS:8888.google, DNS:dns64.dns.google,
 IP Address:8.8.8.8, IP Address:8.8.4.4,
 IP Address:2001:4860:4860:0:0:0:0:8888,
 IP Address:2001:4860:4860:0:0:0:0:8844,
 IP Address:2001:4860:4860:0:0:0:0:6464,
 IP Address:2001:4860:4860:0:0:0:0:64

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

Однако в теории тот же браузер может потребовать, чтобы в сертификате и имя хоста совпадало, и IP-адрес, по которому установлено TCP-подключение. Двойная проверка.

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

На одном IP-адресе может размещаться большое количество веб-узлов с разными именами. Но это не является препятствием для того, чтобы вписать для всех этих узлов один и тот же IP-адрес в сертификат. Сертификат может быть выпущен только для IP-адреса. Например, такие сертификаты обещает даже Let’s Encrypt. Но если обращение к узлу происходит в контексте, где нет DNS-имён, то можно использовать сертификат только с IP-адресом, и если бы был возможен контекст, в котором есть только DNS-имя, то сгодился бы сертификат только с именем, как сейчас. Так что тут проблемы нет. Тем более, если сертификаты начинают выпускаться всего на несколько дней.

Проблемы возникнут при попытке замены IP-адресов в DNS – нужно будет согласовывать такую замену с выпуском новых сертификатов. IP-адреса могут выбираться из большого пула и, конечно, строго привязывать их при помощи TLS-сертификата и к DNS-имени, и к серверу на уровне приложения не очень-то удобно. А соответствие адресов именам в DNS, вообще-то, подтверждает DNSSEC, тоже при помощи электронной подписи. Но DNSSEC – редкая технология.

Сообщают, что CA/B-форум принял решение сократить к 2029 году максимальный срок действия TLS-сертификата до 47 дней. В принципе, это давно ожидалось. Скорее всего, могут даже сдвинуть срок раньше, да и максимальный интервал – сократить (дней до 14, скажем). Я в прошлом году писал в заметке о шестидневных сертификатах Let’s Encrypt:

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

Процесс, скорее всего, коснётся и сертификатов, которые выпускаются от собственных УЦ, не входящих в CA/B-форум.

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

Но необходимо учитывать и другую сторону решения. Сертификаты превращаются в квитанции, разрешающие доступ. Что-то вроде тикетов в каком-нибудь Kerberos. Короткие сертификаты означают, что веб-узлам придётся плотно привязаться к внешней централизованной системе. Те же 47 дней, это даже не три месяца от Let’s Encrypt. Всякий веб-узел должен будет постоянно и в автоматическом режиме отмечаться на центральном сервере, который станет выдавать (или не выдавать) подтверждение, что браузерам всё ещё разрешено к этому веб-узлу подключаться.

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

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

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

В короткоживущих TLS-сертификатах Let’s Encrypt вообще не планируется указывать информацию о механизмах проверки отзыва: ни OCSP, ни CRL. То есть, будет только истечение срока действия сертификата. Новая парадигма. Актуальные требования CA/B-форума как раз позволяют для короткоживущих сертификатов так делать – изменения внесли относительно недавно: сперва сделали OCSP опциональным для всех (что очень правильно), а потом добавили исключение CRL для короткоживущих сертификатов.

Интересно, что истечение срока действия, как метод придания сертификату “недействительности”, гораздо сильнее, чем неработающая проверка отзыва. То есть, отзыв, действительно, мало кто проверяет, а вот срок действия – проверяют едва ли не повсеместно. Ну, как минимум, гораздо чаще проверяют, чем отзыв. Например, те же браузеры, как основной клиент веба, срок действия отслеживают достаточно строго. При этом, если для оформления отзыва нужно предпринимать какие-то действия со стороны УЦ, то обработка истечения срока действия – исключительно на стороне клиента.

В Let’s Encrypt выпустили первый TLS-сертификат со сроком действия шесть дней. Пишут, что сертификаты на шесть дней не будут содержать не только ссылки на OCSP, но и ссылки на CRL. То есть, механизмов проверки отзыва – не будет. В опубликованном сертификате, впрочем, адрес OCSP-респондера почему-то указан. Обратите внимание, что в сертификате поле Subject вообще пустое – это тоже новый формат: указание Subject/CN некоторое время назад сделали опциональным. Сам сертификат – ниже.

-----BEGIN CERTIFICATE-----
MIIDSzCCAtGgAwIBAgISA7CwFcGk4mQWEXMacRtxHeDvMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
NjAeFw0yNTAyMTkxNzMwMDFaFw0yNTAyMjYwOTMwMDBaMAAwWTATBgcqhkjOPQIB
BggqhkjOPQMBBwNCAAQoSItt2V1aocI5dxrKR8iLfmm0KiVvOhiwKByzu2kLeC7C
0BdfAgtwdICdkuEhAXokhXLq6DNZZgmh5T4flVwZo4IB9zCCAfMwDgYDVR0PAQH/
BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHwYDVR0j
BBgwFoAUkydGmAOpUWiOmNbEQkjbI79YlNIwVQYIKwYBBQUHAQEESTBHMCEGCCsG
AQUFBzABhhVodHRwOi8vZTYuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6
Ly9lNi5pLmxlbmNyLm9yZy8wKAYDVR0RAQH/BB4wHIIaaGVsbG93b3JsZC5sZXRz
ZW5jcnlwdC5vcmcwEwYDVR0gBAwwCjAIBgZngQwBAgEwggEFBgorBgEEAdZ5AgQC
BIH2BIHzAPEAdgDM+w9qhXEJZf6Vm1PO6bJ8IumFXA2XjbapflTA/kwNsAAAAZUf
d/zOAAAEAwBHMEUCIFNd51TfSNiJrO+294t49C5ANc4oC7gTUzf7xnlNlhKsAiEA
wi5hfiC9SsKLxlTQ0sctUxhLmdYh40r6ECWQS/yWw2AAdwDgkrP8DB3I52g2H95h
uZZNClJ4GYpy1nLEsE2lbW9UBAAAAZUfd/0TAAAEAwBIMEYCIQCs2NuZIUIloOaH
1t9eXDKb8bjoWESBPsK4i2BxMvEIswIhAOMNaQNyr1YkzrcNUz15qGV0oVLg5BJN
+ikWxXOdcRHFMAoGCCqGSM49BAMDA2gAMGUCMDANqy7G09AIwzXcd7SNl7uFwhC+
xlfduvp1PeEDHc/FA9K3mRYkGXuKtzNdOh7wcAIxALjEMDmBQiwXbB447oGkaZAe
0rqxA3EtNV5wj0obeObluj/NgUsVEG9OqiBIoggFRw==
-----END CERTIFICATE-----