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]