DNS-аутентификация именных объектов (DANE) – отличная функция, которая использует преимущества подписанной зоны DNSSEC, чтобы сообщить клиенту, какой сертификат TLS он должен ожидать при подключении к безопасному адресату через HTTPS или SMTPS. Через безопасный канал (DNSSEC) клиент может запросить открытый ключ сервера. Это означает, что атака «Человек-в-середине» (MITM) с поддельным сертификатом будет выставлена напрямую, т. е. больше невозможно. Кроме того, доверие к органам сертификации (ЦС) больше не требуется.

Этот пост является частью серии о DNSSEC.

В моих последних сообщениях я рассмотрел безопасную установку BIND как авторитетного DNS-сервера, а также реализацию DNSSEC. Это действительно обязательно, потому что без подписанной зоны DNS DANE будет бесполезной. Хотя я использую BIND для приведенных ниже примеров, DANE можно использовать с любым другим DNS-сервером.

Что такое DANE?

Реферат RFC 6698 «DNS-аутентификация протокола NLS (TLS):« TLSA », в котором предлагается DANE, описывает довольно хорошее значение DANE:« Зашифрованная связь в Интернете часто использует транспорт Layer Security (TLS), которая зависит от третьих сторон для сертификации используемых ключей. Этот документ улучшает эту ситуацию, позволяя администраторам доменных имен указывать ключи, используемые на серверах TLS этого домена. Это требует соответствующих улучшений в клиентском программном обеспечении TLS, но без изменения программного обеспечения сервера TLS ».

Сегодня браузер устанавливает безопасное соединение TLS с известным сервером (DNS-имя) с сертификатом «unkown» (не подтвержденным конечным пользователем). Мы полагаемся на центры сертификации (ЦС), которые когда-то проверяли сертификат, принадлежащий оператору сервера. К несчастью, любой (!) СА может подписать каждый (!) Сертификат в мире, даже если сертификат НЕ принадлежит самому серверу, а вредоносному третьему лицу, которое хочет перехватить безопасное сообщение через man-in -средняя (MITM) атака.

С новой записью ресурсов DNS «TLSA» хэшированный открытый ключ публикуется на DNS-сервере того же органа / объекта, которому принадлежит сервер TLS, например HTTPS-сервер или почтовый шлюз SMTPS. Теперь клиент конечного пользователя может действительно подтвердить, что сертификат сервера TLS принадлежит той же организации, которая владеет сервером DNSSEC. Следовательно, атаки MITM с поддельными сертификатами больше невозможны.

Создание записей TLSA

Серверы TLS не должны вносить изменений. Единственное, что нужно сделать, – разместить хэшированный открытый ключ в зоне DNS. Для наиболее распространенных сценариев поля в записи TLSA следующие (см. RFC 7671, раздел 5.1):

Использование: 3 – DANE-EE: сертификат выданного домена
Селектор: 1 – SPKI: использование открытого ключа объекта
Тип соответствия: 1 – SHA-256

Для создания записей TLSA на месте может быть использован инструмент «tlsa» из инструментария «hash-slinger». На сервере Ubuntu это работает следующим образом:

sudo apt-get install hash-slinger

Генерируем TLSA запись

tlsa --create --selector 1 --certificate сертификат-ssl.crt ваш_хость.ru

копируем содержимое в DNS зону

443._tcp.вашхость.ru. IN TLSA 3 1 1 0d6fce3320315023ff499a3f3de1c362c88f8380311ac8c036890dab13243aa7

Проверяем

dig _443._tcp.host-dane.weberdns.de tlsa +dnssec +multi

[endtxt]

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

5 1 голос
Рейтинг статьи

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Продолжая пользование настоящим сайтом Вы выражаете своё согласие на обработку Ваших персональных данных (файлов cookie) с использованием трекеров "Google Analytics" и "Yandex.Metrics". Порядок обработки Ваших персональных данных, а также реализуемые требования к их защите, содержатся в Политике конфиденциальности.
Принять