CAA и DNSSEC вкратце: как, зачем и поверхность атаки
В рамках проекта «Монитор госсайтов» мы стараемся не только демонстрировать, какие все кругом неумехи и лодыри (а мы — в белом жабо), но и показать, что безопасность веб-сайта — это просто, приятно и полезно. Сегодня расскажем о паре технологий, поддержка которых относится к группе А+ нашей методики, то есть желательно, но не обязательно — CAA и DNSSEC.
DNS Certification Authority Authorization (CAA) Resource Record
Если вы погрузитесь в изучение NS-записей для нашего домена (ifap.ru), то найдете среди них две записи CAA:
CAA ifap.ru 14400 128 issue letsencrypt.org
CAA ifap.ru 14400 128 iodef mailto: contact@ifap.ru
Эти записи содержат список УЦ, которым администратор домена разрешил выдавать для него TLS-сертификаты, и адрес электропочты, на который остальные УЦ просят ябедничать о (несанкционированных) попытках получить сертификат у них. Подробный рассказ, что означают цифры в этих записях и какие еще символы можно к ним добавить, приведен в IETF RFC 6859, а удобный инструмент для генерации CAA-записей без выноса самому себе мозга предлагает, например, SSLMate. Я же перескажу ключевое с точки зрения обеспечиваемой CAA безопасности сайта.
CAA запись — это просьба администратора доменного имени добропорядочным УЦ: по газону не ходить! Прислушаться ли к этой просьбе, зависит исключительно от доброй воли УЦ при условии, что до него эта просьба дойдет и он не посчитает необязательным ее исполнение в силу текущей политической ситуации или собственных представлений об идеальном мироустройстве. УЦ — члены CA/Browser Forum теоретически обязаны исполнять предписания CAA, но на пике очередной волны хайпа солидарности правилами можно пренебречь, получив за это вместо полагающихся а-та-ташенек аплодисменты задающего повестку охлоса.
Кроме шуток: именно так и умирают идеалы свободы, заложенные в фундамент Всемирной паутины — под гром оваций толпы, заглушающий вскрики отдельных здравомыслящих, которых режут фанатики (ради достижения еще более великих и светлых идеалов, разумеется).
Есть и другие нюансы. Если злоумышленник получит доступ к управлению ресурсными записями для вашего домена, то ничто не помешает ему изменить и CAA-запись. Если злоумышленник сможет завернуть запрос CAA-записи со стороны УЦ на «левый» NS-сервер, то УЦ получит нужный злоумышленнику ответ. Если злоумышленник сам выпустит TLS-сертификат для вашего сайта и убедит аудиторию доверять ему, то CAA никак не поможет. Такова поверхность атаки на CAA. Чтобы снять часть этих проблем, в CAA запись можно добавить информацию о методе проверки прав на запрос сертификата, например:
CAA ifap.ru 14400 128 issue letsencrypt.org; validationmethods=http-01
При этом выбранный метод должен поддерживаться как УЦ, так и используемым ACME-клиентом (при его наличии). Подробно о разных способах проверки можно почитать у Let’s Encrypt, ниже я приведу лишь основные различия.
Проверка по HTTP (validationmethods=http-01): УЦ выдает заявителю «пароль», который тот должен разместить на сайте, для которого запрашивается сертификат. Таким образом постулируется, что злоумышленник, запрашивающий TLS-сертификат для чужого сайта, предполагает его использовать без доступа к веб-серверу (иначе для него не составит труда пройти проверку), например ради демонстрации PoC или достижения иных альтруистических целей. Кстати, HTTP в данном случае означает буквально HTTP, а не HTTPS.
Проверка по DNS (validationmethods=dns-01): УЦ выдает заявителю «пароль», который тот должен разместить в TXT-записи на авторитетном для соответствующего доменного имени NS-сервере. Таким образом постулируется, что злоумышленник, запрашивающий TLS-сертификат для чужого сайта, возможно, имеет к доступ к веб-серверу, но не имеет доступа на запись к NS-серверу, что более правдоподобно. Хорошее комбо получается, если этот метод проверки используется в сочетании с поддержкой DNSSEC.
Проверка по TLS c SNI или ALPN (validationmethods=tls-sni-01 или validationmethods=tls-alpn-01 соответственно): аналогична проверке по HTTP, но есть нюанс, и не один. Во-первых, проверка выполняется уже по HTTPS. Во-вторых, первый вариант считается небезопасным и устаревшим. В-третьих, второй вариант настолько передовой, что поддерживается чуть более чем никем из УЦ.
Подытожим: CAA — просьба к УЦ вести себя прилично, которую все авторитетные УЦ, скорее всего, исполнят, если эта просьба будет ими услышана и они захотят ее исполнить.
— Вы, сэр?
— Да, сэр!
— Что, сэр?
— Я, сэр!
— Слово, сэр?
— Джентльмена, сэр!
— Я рад, что в Вас не ошибся!
Domain Name System Security Extensions (DNSSEC, а точнее — DNSSEC-bis)
Надстройка над протоколом DNS, прикручивающая к нему иерархическую систему доверия на основе сертификатов ЭП, которая позволяет «вышестоящим» DNS-серверам удостоверять легитимность нижестоящих.
Схематично и весьма упрощенно эта система выглядит следующим образом: например при разрешении доменного имени ifap.ru в IP-адрес браузер обращается к рекурсивному DNS-серверу с просьбой сообщить, какой IP-адрес сопоставлен доменному имени ifap.ru. Рекурсивный DNS-сервер спрашивает у одного из корневых DNS-серверов: где искать ответственного за TLD .ru? Адреса корневых DNS-серверов и открытые ключи их ЭП уже имеются у рекурсивного DNS-сервера (аналогично постоянному хранилищу TLS-сертификатов авторитетных корневых УЦ в браузерах).
Корневой DNS-сервер отвечает, подписывая (но не шифруя) свой ответ: авторитетный для TLD .ru DNS-сервер расположен по адресу dns.ripn.net, открытый ключ его ЭП прилагается (при условии, что авторитетный для соответствующего TLD DNS-сервер поддерживает DNSSEC). Рекурсивный DNS-сервер обращается с вопросом к dns.ripn.net и проверяет подпись ответа с помощью присланного свыше открытого ключа.
Для справки: DNS-сервера, отвечающие за TLD .ru, поддерживают DNSSEC, однако он используется на примерно 0,1% сайтов в TLD .ru.
История повторяется, пока рекурсивный DNS-сервер не узнает IP-адрес самого ifap.ru, причем не от кого-то, представляющегося авторитетным DNS-сервером для ifap.ru, а от того, чья авторитетность и неизменность (но не достоверность — об этом ниже) ответа были заверены цепочкой ЭП, восходящей к одному из 13 корневых DNS-серверов.
При этом, напоминаю, ответы DNS-серверов лишь подписаны, но не зашифрованы т.е. доступны для прослушивания (не следует путать DNSSEC с DoH/DoT), а электронная подпись позволяет проверить лишь неизменность всей «переписки», но не ее достоверность (то есть от намеренной лжи вышестоящего DNS-сервера DNSSEC не спасет). И, наконец, клиент должен быть уверен, что DNS-резолвер передаст ему неизменный ответ, и в эту передачу не вмешалась третья сторона.
В связи с последней оговоркой важно отметить, что в большинстве научно-популярных рассказов про DNSSEC, описывающих схему его работы в клиент-серверных терминах, клиентом называется все что угодно, кроме того, что под ним обычно понимает читатель: компьютер или ПО (например, браузер) конечного пользователя. При этом практически всегда прямо или явно заявляется, что общение «внутри» DNSSEC заверено ЭП и потому априори надежно, что верно, но при этом вводит неискушенного читателя в заблуждение.
На самом деле информационный обмен между клиентским устройством (ПК, смартфоном) и рекурсивным DNS-сервером при разрешении доменных имен в IP-адрес электронной подписью не заверяется, он лишь содержит декларации: «я, клиент, осведомлен о существовании DNSSEC» и «я, резолвер, мамой клянусь, что искал IP через DNSSEC».
Соответственно вся наша красивая схема подвержена проблеме «последней мили»: если резолвер не расположен на устройстве самого пользователя или если не используется DoH/DoT, в результате сложноподписанных DNSSEC запросов-ответов пользователь получает фактически неподписанный DNS-ответ и не получает никаких гарантий, что этот ответ не был изменен на «последней миле». Серверные ОС с поддержкой DNSSEC и активированной ролью DNS-сервера снимают эту проблему (если вам был нужен лишний довод в пользу серверных ОС на десктопе — это он).
В связи с этим стоит подчеркнуть, что большинство DNS-запросов не будут отправляться на корневые DNS-сервера, а разрешатся уровнем-двумя-тремя ниже, в лучшем случае — на уровне «реплик» корневых DNS-серверов, коих в мире насчитывается 1756, из них 18 (я ни на что не намекаю) в России.
Поэтому поверхность атаки на DNSSEC чрезвычайно широка и разнообразна, ведь клиент агент пользователя принимает ответ рекурсивного DNS-сервера на веру, а сам рекурсивный сервер знает лишь, от кого пришел подписанный ответ, но не знает, правду ему ответили или нет. Впрочем, рекурсивный сервер может и не знать заранее, поддерживается ли DNSSEC искомым сайтом, авторитетными для него и соответствующей зоны DNS-серверами, соответственно, должен ли ответ на DNS-запрос придти с подписью или без со всеми вытекающими из этого последствиями.
И даже если вся цепочка авторитетных для условного ifap.ru серверов, а также сам условный ifap.ru поддерживает DNSSEC (реальный ifap.ru — не поддерживает), это вовсе не значит, что его поддерживает и используемый вами рекурсивный DNS-сервер. В качестве последнего демотиватора замечу, что в популярных ОС «из коробки» не предусмотрен способ узнать, уверяет ли рекурсивный DNS-сервер, что ваш DNS-запрос делается через DNSSEC.
Подытожим: DNSSEC — способ удостовериться, что в результате разрешения имени хоста в IP-адрес доверенный рекурсивный DNS-сервер, соединение с которым не могло быть скомпрометировано, получил достоверный IP от DNS-сервера, который все DNS-сервера в цепочке вплоть до корневого считают авторитетным для искомого доменного имени. Еще раз подчеркну, что в самом лучшем случае речь идет лишь о достоверности информации об авторитете DNS-серверов, а не достоверности их ответов.
Если у вас сложилось впечатление, что DNSSEC — бесполезная технология, которая ничего не дает рядовому пользователю, вы отчасти правы — просто это технология, которая предназначена не для рядовых пользователей, а для серверов, и настройкой пресловутого «клиента» там занимаются не домохозяйки, а профессионалы. Во всяком случае, в теории…
Общий вывод: CAA — хорошо, DNSSEC — еще лучше, CAA с проверкой по DNS + DNSSEC = хорошее, но вовсе не непробиваемое комбо, которое желательно усилить использованием DoH/DoT для решения проблемы «последней мили».
