DNSSEC - Как он защищает от атаки MITM?
Я уже несколько часов читал о DNSSEC и до сих пор не могу понять, как он защищает от атак MITM . Я также прочитал здесь все вопросы о сбое сервера, связанные с DNSSEC .
Пожалуйста, взгляните на этот DNSSEC захват пакетов: https: //www.cloudshark. org / captures / 79e23786259b
Что мешает MITM перехватывать каждый запрос и отвечать своими собственными парами ключей на каждые DNSKEYS , RRSIG [11126286287] и ] DS записи?
Например, MITM будет генерировать RRSIG для www.ietf.org, затем DNSKEYS для ietf.org , затем запись DS для ietf.org . Затем еще один набор записей DNSKEYS и DS для "org", а затем снова для .
В TLS мы можем доверять цепочка доверия с центрами сертификации, потому что корневые центры сертификации предварительно установлены в каждой системе, поэтому мы можем проверять ответы на них. В DNSSEC , Я не верю, что корневой DNSKEY установлен в таких системах, как корневые центры сертификации. Так почему же мы можем доверять полученному корневому ключу?
Эта проблема решается с помощью цепочки доверия : каждое звено в этой цепочке подписано DS записи в предыдущей зоне, как уже упоминалось в вашем вопросе. Это подчеркивает важность привязки на корневых серверах имен. Если это было подделано,вся цепочка доверия была скомпрометирована. Следовательно, преобразователи должны быть предварительно настроены с помощью якоря доверия . RFC 6781 объясняет:
4.2.3. Компрометация ключей, закрепленных в преобразователях
Ключ также может быть предварительно настроен в преобразователях в качестве якоря доверия. Если ключи якоря доверия скомпрометированы, администраторы резолверы, использующие эти ключи, должны быть уведомлены об этом факте. Зона администраторы могут подумать о создании списка рассылки для общения тот факт, что ключ SEP вот-вот будет отменен. Этот связь, конечно, должна быть аутентифицирована каким-либо образом, например, с помощью цифровых подписей.
Конечные пользователи, столкнувшиеся с задачей обновления привязанного ключа, должны всегда проверяйте новый ключ. Новые ключи должны быть аутентифицированы вне группы, например, с помощью веб-сайта объявлений, который защищено с помощью Transport Layer Security (TLS) [RFC5246] .
Вы можете загрузить Current Root Trust Anchors ( bind.keys ) прямо из Интернета Системный консорциум. Сайт защищен с помощью TLS, и файл также подписан их ключом подписи.
Если у вас ничего нет в
named.confи нетbind.keysфайл с именем будет использовать скомпилированные ключи.Примечание: это управляемые ключи, поэтому это применимо только в первый раз выполняешь named. Предполагая, что срок действия ключей еще не истек (в в каком случае будет записано, что срок действия ключа истек, и проверка будет не работает), named будет использовать RFC 5011 для обнаружения новых ключей и автоматически катить и поддерживать ключи. Однажды названный управляет ключами, текущие ключи будут в
managed-keys.bindили*. mkeys, если вы используете просмотров.
Еще одна проблема - связь с вашим решателем, «последняя миля». Резолвер может проверять подписи и отвечать битом DNS Authenticated Data (AD), но поскольку DNS работает в виде обычного текста, результаты могут быть изменены посредником (MITM) злоумышленник. Для этого есть несколько возможных решений:
У вас может быть собственный локальный преобразователь, имеющий файл ключей привязки, но это не совсем практичное решение для масс. Это также приводит к увеличению трафика на корневые серверы имен, если не настроены пересылки. Это решение «никому не доверять», в котором вы проверяете подписи самостоятельно.
DNS-over-TLS & DNS-over-HTTPS . Например. Cloudflare с их
1.1.1.1поддерживает оба :Что необходимо, так это переход на новый, современный протокол. Есть пара разных подходов. Один из них - DNS-over-TLS. Это требует существующих Протокол DNS и добавляет шифрование транспортного уровня. Другой DNS-over-HTTPS. Он включает в себя безопасность, но также и все современные такие улучшения, как поддержка других транспортных уровней (например, QUIC) и новые технологии, такие как сервер HTTP / 2 Server Push. И DNS-over-TLS, и DNS-over-HTTPS - это открытые стандарты.
Мы считаем, что DNS-over-HTTPS особенно многообещающе - быстро, проще разобрать и зашифровать. - - Мы надеемся, что теперь доступна независимая служба DNS-over-HTTPS, мы увидим больше экспериментов из браузеров, операционных систем, маршрутизаторов и приложений для поддержки протокола.
DNSCrypt аутентифицирует обмен данными между клиентом DNS и преобразователем DNS, используя криптографические подписи. Это никогда не предлагалось IETF (там нет RFC).
Помимо обширного ответа Эсы Йокинена, давайте вернемся к:
Я не верю, что корневой DNSKEY установлен в таких системах, как корневые центры сертификации. Это ваше ложное предположение, которое порождает все последствия, которые вы правильно описываете.
Но корневой DNSKEY действительно поставляется с резолверами. Это создает другие проблемы, особенно после запланированной смены этого ключа (это было запланировано на последний октябрь, но было отложено).
У вас действительно есть начальная загрузка DNSSEC. Программное обеспечение должно иметь внешний ключ, но также может потребоваться его обновление. Что произойдет, если вы купите продукт сегодня и, следовательно, поставляете с текущим ключом, оставите его в таком состоянии на 2 года, а затем включите его, когда текущий корневой ключ DNSKEY будет заменен другим?
Вы можете вообразить много вещей. вроде ... давайте, конечно же, возьмем ключ с веб-сайта IANA через HTTPS! Кроме того, для этого вам необходимо разрешить имя веб-сайта IANA, и, следовательно, вы зависите от DNS и связанного с ним DNSSEC, который вы просто пытаетесь настроить. И, конечно, вы также не будете жестко кодировать IP-адреса веб-сайтов IANA. Или вы можете представить себе, что просто полагаетесь на TLS, так как вы даже можете обмениваться цепочками доверия DNS / DNSSEC во время рукопожатия TLS ... за исключением того, что это означает, что вам нужно отправить сертификат CA, который сам может измениться (даже если мы можем сказать сейчас что сертификаты CA существуют / будут длиться дольше, чем корневой ключ DNSSEC ... за исключением того, что с Let's Encrypt мы также можем представить будущее с более короткими CA ...), так что вернемся к исходной точке.
Проблема с курицей и яйцом.
Вы можете узнать больше об этой проблеме и ее решениях в этом документе, например: https://datatracker.ietf.org/doc/draft-jabley-dnsop-bootstrap-validator/ В этом документе обсуждается подход к автоматической настройке доверять якорям в валидаторе DNSSEC.
Если у вас уже есть действующий (текущий) корневой ключ DNSSEC, существует особая процедура, которой необходимо следовать для автоматического безопасного переключения на новые ключи, когда они произойдут: Автоматические обновления якорей доверия безопасности DNS (DNSSEC)