Зачем нам нужен DNSSEC? ( howdnssec.works )
Мы не делаем этого. Если бы мы делали это, мы бы уже это сделали. Прошло более 25 лет с момента подачи подобных обращений.
Это забавный сайт! Я не совсем уверен, почему главный герой — зеленое тако, но я могу понять, почему поставщик DNS сделал мультяшное объяснение протокола. Просто этот конкретный протокол не так важен, как звучит из его названия.
> Мы не делаем этого. Если бы мы делали это, мы бы уже это сделали. Прошло более 25 лет с момента подачи подобных призывов.
См. также IPv6. 😉
Это важно. Это досадная риторика, которая вредит безопасности интернета.
«Например, в апреле 2018 года российский провайдер объявил ряд IP-префиксов (групп IP-адресов), которые на самом деле принадлежат DNS-серверам Amazon Route53».
Используя BGP-перехват Route53, злоумышленники не только смогли перенаправить веб-сайт на разные IP-адреса по всему миру, но и сгенерировать SSL-сертификаты для этого веб-сайта. Они использовали это, чтобы украсть 152 000 долларов в криптовалюте. (Я знаю, я знаю, «криптовалюта», но это может случиться с любым сайтом: банковским, медицинским, инфраструктурным)
Также, прежде чем вы скажете, RPKI тоже не решает эту проблему, хотя и является шагом в правильном направлении. DNSSEC также является шагом в правильном направлении.
[1] https://www.cloudflare.com/learning/security/glossary/bgp-hi…
DNSSec на данный момент стал причиной стольких сбоев, что это просто смешно.
Нужно быть невероятно осторожным и планировать все до мельчайших подробностей, иначе все сломается: https://internetnz.nz/news-and-articles/dnssec-chain-validat…
Идея важна. То, что она призвана защищать, важно. Текущая реализация ужасна, слишком сложна и переполнена таким количеством земельных разумов, что никто не хочет к ней прикасаться.
Если Джефф Хьюстон предполагает, что пришло время вставить вилку в DNSSec, поскольку он уже готов, то, по моему скромному мнению, он уже хорошо приготовлен. https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/
Да, я ни в коем случае не говорю, что реализация хороша. RPKI тоже, по-моему, шутка. Но это все, что у нас есть сейчас.
Я утверждаю, что нечестно игнорировать реальную угрозу безопасности, возникающую из-за отсутствия DNSSEC.
Аргумент против DNSsec заключается в том, что если вы пытаетесь найти случайную запись A для сервера, чтобы узнать, является ли она правильной, TLS прекрасно с этим справится, если вы разумно доверяете работе проверки контроля домена, т. е. центрам сертификации (CA) видна подлинность DNS.
Аргументом в пользу DNSSEC является любая служба, настроенная записями SRV. Для записи srv чего-либо может быть совершенно законным указывать на запись A в совершенно другой зоне. С точки зрения TLS вы не можете этого сказать, потому что делегирование произошло с помощью записей SRV, и вы узнаете, является ли это подлинным, только если у вас есть подписанная запись или прямое зашифрованное соединение с авторитетным сервером (соединение TLS с evil.service.example будет действительным).
Так что все зависит от того, чего вы ожидаете от DNS.
TLS не обеспечивает никакой безопасности в этом случае, поскольку сертификаты TLS генерируются на основе DNS. См. Lets Encrypt.
Атаки BGP изменяют семантическое значение самих IP-адресов. DNSSEC работает на уровне выше. Единственное место, где это имеет значение в пост-HTTPS-везде-мире, — это центры сертификации, которые теперь все переходят на многоперспективную проверку.
И, по крайней мере, Let's encrypt действительно проверяет DNSSEC перед выдачей сертификатов. Думаю, это скоро станет обязательным для всех CA. DNSSEC для домена плюс ограничительные правила CAA должны гарантировать, что ни один авторитетный CA не выдаст мошеннический сертификат.
Этого точно не будет. Большинство доменов изначально не взламываются путем подмены DNS.
“Большинство доменов”. Да, возможно, никто не беспокоится о DNS-перехвате ваших доменов. К сожалению, я работал в организациях, где это случалось, и теперь у них есть DNSSEC.
Я предлагаю всем, кто думает, что это подстава, открыть список Tranco research самых популярных/важных доменов в Интернете (это просто текстовый файл с зонами, по одной в строке) и написать тривиальный цикл bash `for`, чтобы `dig +short ds` для каждой из этих зон и посчитать, сколько из них имеют DNSSEC.
Для начала вы можете попробовать `dig +short ds google.com`. Это даст вам представление о том, чего ожидать.
Как вам должно быть известно, многоперспективная проверка ничего не решает, если ваш захват BGP принят как глобальный. Вы получите 100% трафика.
DNSSEC оказывает большую помощь в решении этой проблемы: он мог бы предотвратить указанный инцидент.
Злоумышленнику BGP не нужно изменять DNS для перехвата трафика; он уже перехватывает целевой трафик на уровне селективности IP.
Есть два способа осуществить эту атаку:
1. Взломать сервер HTTP/HTTPS. Для некоторых диапазонов IP это совершенно неосуществимо. Например, взлом диапазона HTTP/HTTPS CloudFlare был бы практически невозможен теоретически, исходя из технических деталей, которые я не буду перечислять.
2. Взломать DNS-сервер. Поскольку существует полное равнодушие к безопасности DNS-сервера (как вы показываете), эта атака очень часто игнорируется. Именно поэтому в упомянутом инциденте злоумышленники смогли с легкостью взломать Amazon Route53. *DNSSEC решает эту проблему.*
Если 1 или 2 сработали, вы успешно взломали сайт. Оба должны быть безопасными, чтобы предотвратить это.
Подводя итог, вы предлагаете радикальное обновление DNS, требующее сотен миллионов долларов усилий от операторов по всему миру, внедряя систему, которая регулярно полностью отключает некоторые из самых сложных платформ от Интернета, когда их хрупкая конфигурация выходит из строя, чтобы решить проблему глобального перехвата всех адресов Route53 кем-то.
На этом этапе вы могли бы просто заставить CABForum придумать новый благословенный метод проверки на основе RDAP. Это действительно может произойти, в отличие от DNSSEC, который этого не сделает. DNSSEC терял подписанные зоны в Северной Америке в течение нескольких последних интервалов.
Мне нравится, что предлагаемая вами модель угроз применима только к сайтам, работающим за Cloudflare.
«Мне нравится, что предлагаемая вами модель угроз применима только к сайтам, работающим за Cloudflare».
Предложенная мной модель угроз является последовательной для Cloudflare, поскольку они проделали большую работу по проектированию, чтобы сделать практически невозможным глобальный захват их IP-адресов с помощью BGP. Это делает многоперспективную проверку действительно полезной. Да, другие интернет-провайдеры гораздо более уязвимы, чем Cloudflare, есть ли смысл?
Вы не говорите, что DNSSEC не служит реальной цели. Вы говорите, что его неудобно внедрять, и он не получил широкого распространения. Это само по себе заставляет меня считать ваши аргументы немного нечестными, и я воздержусь от дальнейшего обсуждения.
Нет, я говорю, что это не служит реальной цели. Я 30 лет профессионально занимаюсь безопасностью, и одна из основных вещей, которую я понял, заключается в том, что безопасность по сути является экономической проблемой. Работа защитника заключается в асимметричном повышении расходов для злоумышленников. Посмотрите, как сегодня перехватываются зоны DNS и сертификаты. Вы предлагаете радикально повысить расходы защитника таким образом, чтобы это не повлияло существенно на расходы злоумышленников , потому что они в основном не используют экзотическую атаку, на которой вы зациклились.
Если бы мы действительно хотели решительно противостоять этому вектору атаки, мы бы на уровне CA полностью отказались от использования протокола DNS, используемого браузерами для поиска имен хостов, и заменили бы его прямой аттестацией от регистраторов, которую можно было бы сделать _произвольно_ безопасной без странных жестов, которые DNSSEC использует для одновременного обслуживания массовых поисков из браузеров и этого варианта использования CA.
Но речь идет не о реальных моделях угроз. Речь идет о крошечном меньшинстве технологов, имеющих парасоциальные отношения с устаревшим протоколом.
О чем вы говорите? Речь идет о реальных моделях угроз. DNS-перехваты реальны и документированы. DNSSEC решает их.
Больше похоже на то, что у вас парасоциальные отношения с DNSSEC (и судя по всему, не очень хорошие).
Вы утверждаете, что большинство случаев перехвата зон DNS происходит из-за того, что злоумышленник по пути перехватывает и подделывает ответы на запросы DNS? Это не так.
Я не говорил “большинство”. Я сказал, что это происходит и документируется.
Я вполне удовлетворен тем, как эта часть ветки представляет эту часть моих аргументов.
Это, конечно, облегчает задачу. Конечно, мы можем обойтись и без этого, но криптографическое подписание записей DNS полезно для ряда вещей.
Контрапункт: нет, это не так, поэтому практически никто этим не пользуется. Даже атака, на которой сосредоточена эта ветка — захват BGP целевых серверов DNSSEC для подделки подписей CA — это заметка об ошибке округления по сравнению с тем, как на практике перехватываются зоны DNS (атаки ATO против поставщиков DNS).
Если бы люди относились к этому серьезно, они бы начали с требования, чтобы каждый поставщик DNS принимал U2F и/или Passkeys, а не вялый TOTP, который многие из них делают прямо сейчас. Но это несерьезно; это просто мотивированное рассуждение в защиту DNSSEC, в сохранении которого некоторые люди странным образом заинтересованы.
Вы снова игнорируете тот факт, что DNSSEC предотвратил бы взлом на $152 000. Да, мы знаем, что организации не всегда серьезно относятся к безопасности. Для тех, кто серьезно, DNSSEC — полезный инструмент.
Нет, это не так. Он пытается и в основном не может справиться с одной ультраэкзотической атакой, за абсолютно огромные деньги, в основном потому, что сообщество интернет-стандартов настолько зависимо от пути, что не может вернуть плохую криптосистему, разработанную в середине 1990-х годов, обратно на чертежную доску. Вы не можете просто так назвать свой путь к принятию этого протокола; люди пытались сделать это годами, и в результате принятие в Северной Америке упало .
Компании, которые вы высмеиваете за несерьёзное отношение к безопасности в целом, тратят на безопасность значительно больше , чем компании, которые её приняли. Ни одна часть вашего аргумента не выдерживает критики.
поскольку простой текст слишком ненадежен, мы должны шифровать все, даже простой текст
чтобы злобные шпионы из вражеского государства не раскрыли наши самые постыдные национальные тайны!
Нам нужно многое из того, чего у нас нет.
Обратите внимание, что без безопасности DNS любой, кто контролирует ваш DNS-сервер или надежно находится на пути к вашему DNS-серверу, может выдавать сертификаты для вашего домена. Единственная контрмера против этого — прозрачность сертификатов, которая позволяет вам громко кричать, что кто-то выдает себя за вас, но не мешает им делать это на самом деле.
В этом случае на поддержку проблемной области, в которую DNSSEC пытается внести свой вклад, тратится огромное количество денег и ресурсов, а тот факт, что она развернута практически в 0% организаций с большими группами безопасности, говорит сам за себя.
Я бы сказал, что это скорее свидетельство плачевного состояния кибербезопасности. Эти “теоретические” атаки случаются. Все просто думают, что это будут не они.
Мое опровержение заключается в том, что корневые ключи DNSSEC могут попасть на Pastebin сегодня вечером, и почти в каждой организации мира никому не придется отправлять сообщение . Это не гипербола.
Вы в основном правы, но я бы надеялся, что некоторые основные компании и организации безопасности получат пейджинг. Корневые центры сертификации и регистраторы доменов и т.п. должны иметь проверку DNSSEC.
К сожалению, DNSSEC немного дорог в плане поддержки, дополнительных ошибок, снижения производительности и т. д. Чтобы избавиться от всех проблем, понадобится кто-то вроде Apple, который включит проверку DNSSEC по умолчанию. Или понадобится эксплуатируемая уязвимость, например, подмена SIM-карты, чтобы убедить Let's Encrypt! и подобные сервисы, зависящие от proof-by-dns, что им необходимо требовать подпись DNSSEC.
Подмена SIM-карты — гораздо более важный вектор атаки, чем перехват трафика по пути/вне пути, и он ближе к тому, как на практике происходит перехват DNS (путем захвата учетных записей у регистраторов).
потому что я могу указать свой центр сертификации в своих записях DNS, и мое приложение может проверить, что сертификат CA получен из надежного/проверенного источника
Рассказчик: Мы этого не делаем.
Пейджинг tptacek
Source: news.ycombinator.com