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

Почему-то очередную “кросс-протокольную” атаку под названием 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-----

Один из самых распространённых сценариев использования 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: сторона, видевшая запрос, всё равно может подделать ответ.

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