Я уже несколько часов читаю о DNSSEC и я до сих пор не понимаю, как он защищает от MITM атаки. Я также прочитал здесь все вопросы о сбоях сервера, связанные с DNSSEC.
Пожалуйста, взгляните на это DNSSEC захват пакета: https://www.cloudshark.org/captures/79e23786259b
Что останавливает MITM от перехвата каждого запроса и отвечать своими собственными парами ключей для каждого DNSKEYS, RRSIG и DS записи?
Например, MITM генерирует RRSIG для www.ietf.org, затем DNSKEYS для ietf.org, затем DS запись для ietf.org. А потом еще один набор DNSKEYS и DS записи для "org", а затем еще раз для <Root>.
В TLS мы можем доверять цепочке доверия с центрами сертификации, потому что корневые центры сертификации предварительно установлены в каждой системе, поэтому мы можем проверять ответы на них. В DNSSEC, Не верю в рут DNSKEY устанавливается в таких системах, как корневые центры сертификации. Так почему же мы можем доверять полученному корневому ключу?
Эта проблема решается с помощью цепь доверия: каждое звено в этой цепочке подписано DS запись (ы) в предыдущей зоне, как уже упоминалось в вашем вопросе. Это подчеркивает важность якорь на корневых серверах имен. Если это было подделано, весь цепь доверия был скомпрометирован. Следовательно, резолверы должны быть предварительно настроены с якорь доверия. RFC 6781 объясняет:
4.2.3. Компромиссы ключей, закрепленных в резольверах
Ключ также может быть предварительно сконфигурирован в резолверах в качестве якоря доверия. Если ключи якоря доверия скомпрометированы, администраторы преобразователей, использующие эти ключи, должны быть уведомлены об этом факте. Администраторы зоны могут рассмотреть возможность создания списка рассылки, чтобы сообщить о том, что ключ SEP собирается быть продлен. Это сообщение, конечно, должно быть аутентифицировано некоторыми средствами, например, с помощью цифровых подписей.
Конечные пользователи, столкнувшиеся с задачей обновления привязанного ключа, всегда должны проверять новый ключ. Новые ключи следует аутентифицировать вне канала, например, с помощью веб-сайта объявлений, который защищен с помощью протокола TLS. [RFC5246].
Вы можете скачать Текущие корневые якоря доверия (bind.keys) непосредственно из Консорциума Интернет-систем. Сайт защищен с помощью TLS, и файл также подписан их ключом подписи.
Если у тебя ничего нет
named.confи нетbind.keysфайл с именем будет использовать скомпилированные ключи.Примечание: это управляемые ключи, поэтому это применимо только при первом запуске named. Предполагая, что срок действия ключей еще не истек (в этом случае named будет регистрировать, что срок действия ключа истек и проверка не будет работать), named будет использовать RFC 5011 для обнаружения новых ключей и автоматического обновления и обслуживания ключей. После того, как named управляет ключами, текущие ключи будут в
managed-keys.bindили*.mkeys, если вы используете views.
Еще одна проблема - связь с вашим резолвером, «последняя миля». Резолвер может проверять подписи и отвечать с помощью DNS. Аутентифицированные данные (AD) бит, но поскольку DNS работает в виде обычного текста, результаты могут быть изменены злоумышленником по типу «человек посередине» (MITM). Для этого есть несколько возможных решений:
У вас может быть собственный локальный преобразователь с файлом ключей привязки, но это не совсем практичное решение для масс. Это также приводит к увеличению трафика на корневые серверы имен, если не настроены пересылки. Это решение, не требующее доверия, когда вы проверяете подписи самостоятельно.
DNS-поверх-TLS & DNS-поверх-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)