Назад | Перейти на главную страницу

Почему бы не проверять самоподписанные сертификаты через DNS-запись вместо letsencrypt

Мне просто интересно. Мы используем много SSL-сертификатов. В настоящее время мы почти исключительно используем letsencrypt (спасибо!). Суть этих сертификатов заключается в том, что доказательство владения доменным именем (именами) в сертификате исходит из возможности манипулировать записями DNS или веб-сайтом в этих доменах. Доказательство DNS исходит из добавления некоторого ключа (предоставленного letsencrypt) в качестве записи TXT в DNS.

Итак, ЕСЛИ этого достаточно, чтобы иметь возможность изменять записи DNS для домена, почему бы не использовать самоподписанные сертификаты с отпечатком пальца в DNS?

Я бы сказал, что это дает точно такое же доверие, как и основанная на DNS процедура letsencrypt (и других центров сертификации):

  1. Создайте самоподписанный центр сертификации (просто следуйте инструкциям в различных инструкциях)
  2. Создайте сертификат для некоторого домена (ов)
  3. Подпишите сертификат из шага 2 с помощью CA из шага 1. Теперь у вас есть базовый сертификат, подписанный ненадежным центром сертификации.
  4. Добавьте запись TXT (или выделенную) в DNS каждого из доменов, указав: мы подписали сертификат этого домена с этим CA. Например: 'CA = -fingerpint of CA-'
  5. Браузер загружает сертификат и проверяет его, сравнивая отпечаток CA / сертификат CA с данными в DNS для данного домена.

Это позволило бы без вмешательства третьих лиц создавать доверенные самоподписанные сертификаты с таким же уровнем доверия, что и любой базовый сертификат SSL. Пока у вас есть доступ к DNS, ваш сертификат действителен. Можно даже добавить немного DNSSEC, например шифрование, или создать хэш из CA плюс SOA-запись, чтобы убедиться, что доверие исчезает при изменении записи DNS.

Рассматривалось ли это раньше?

Jelmer

Базовая инфраструктура, которая сделает это возможным, существует и называется аутентификацией именованных объектов на основе DNS (DANE) и указана в RFC6698. Работает с помощью TLSA запись ресурса, которая определяет сертификат или его открытый ключ конечного объекта или одного из его центров сертификации в цепочке (на самом деле существует четыре различных типа, подробности см. в RFC).

Принятие

Однако DANE еще не получил широкого распространения. Мониторы VeriSign Принятие DNSSEC и DANE и отслеживает его рост с течением времени:

Для сравнения, согласно VeriSign, существует около 2,7 миллиона зон DNS, а это означает, что чуть более 1% всех зон имеют хотя бы одну запись TLSA.

Я не могу дать авторитетного ответа, почему именно DANE, но вот мои предположения:

DANE страдает той же проблемой, что и списки отозванных сертификатов (CRL) и протокол статуса онлайн-сертификатов (OCSP). Чтобы проверить действительность представленного сертификата, необходимо связаться с третьей стороной. Ханно Бёк дает хороший обзор, почему это большая проблема на практике. Все сводится к вопросу, что делать, если вы не можете связаться с третьим лицом. Поставщики браузеров выбрали мягкий провал (или разрешение) в этом случае, что сделало все это довольно бессмысленным, и Chrome в конечном итоге решил отключить OCSP в 2012 году.

DNSSEC

Возможно, DNS обеспечивает гораздо лучшую доступность, чем серверы CRL и OCSP центров сертификации, но по-прежнему делает невозможным автономную проверку. Кроме того, DANE следует использовать только вместе с DNSSEC. Поскольку обычный DNS работает по протоколу UDP, не прошедшему проверку подлинности, он весьма подвержен подделке, атакам MITM и т. Д. Принятие DNSSEC намного лучше, чем внедрение DANE, но все же далеко не повсеместно.

А с DNSSEC мы снова сталкиваемся с проблемой мягкого отказа. Насколько мне известно, ни одна из основных серверных / клиентских операционных систем не предоставляет по умолчанию проверяющий преобразователь DNSSEC.

Кроме того, существует проблема отзыва. DNSSEC не имеет механизма отзыва и вместо этого использует краткосрочные ключи.

Поддержка программного обеспечения

Все участвующее программное обеспечение должно реализовывать поддержку DANE.

Теоретически вы можете подумать, что это будет работа криптографических библиотек, и разработчикам приложений не придется много делать, но факт в том, что криптографические библиотеки обычно предоставляют только примитивы, а приложениям приходится выполнять большую настройку и настраивать себя (и, к сожалению, есть много способов ошибиться).

Я не знаю, что какой-либо крупный веб-сервер (например, Apache или nginx), например, реализовал DANE или планирует это сделать. Веб-серверы имеют здесь особое значение, потому что все больше и больше вещей строится на веб-технологиях и поэтому они часто являются первыми, где что-то реализуется.

Когда мы смотрим на CRL, OCSP и OCSP Stapling для сравнения, мы можем сделать вывод, как пойдет история внедрения DANE. Только некоторые приложения, использующие OpenSSL, libnss, GnuTLS и т. Д., Поддерживают эти функции. Потребовалось время, чтобы основное программное обеспечение, такое как Apache или nginx, поддержало его, и снова, возвращаясь к статье Ханно Бёка, они ошиблись и их реализация некорректна. Другие крупные программные проекты, такие как Postfix или Dovecot не поддерживает OCSP и имеют очень ограниченную функциональность CRL, в основном указывающую на файл в файловой системе (который не обязательно регулярно перечитывать, поэтому вам придется перезагружать сервер вручную и т. д.). Имейте в виду, что это проекты, в которых часто используется TLS. Затем вы можете начать смотреть на вещи, в которых TLS гораздо реже, например PostgreSQL / MySQL, и, возможно, они в лучшем случае предлагают CRL.

Так что я даже на современных веб-серверах не реализовал это, а у большинства другого программного обеспечения даже не хватило времени для реализации OCSP и CRL, удачи с вашим 5-летним корпоративным приложением или устройством.

Возможные приложения

Так где же на самом деле можно использовать DANE? На данный момент в Интернете нет. Если вы управляете сервером и клиентом, возможно, это вариант, но в этом случае вы часто можете прибегнуть к закреплению открытого ключа.

В почтовом пространстве DANE набирает обороты, потому что SMTP долгое время не имел никакого аутентифицированного транспортного шифрования. SMTP-серверы иногда использовали TLS между собой, но не проверяли, действительно ли совпадают имена в сертификатах, теперь они начинают проверять это через DANE.

Различные типы процедур проверки сертификатов

Для обычных сертификатов, подписанных ЦС, существует несколько уровней проверки сертификатов:

  • Проверка домена (DV)
    Проверяется только право собственности на доменное имя, только доменное имя отображается как «Тема» в сертификате.
  • Проверка организации (OV)
    Имя домена и имя владельца проверяются, имя домена и имя владельца отображаются как «Тема» в сертификате.
  • Расширенная проверка (EV)
    Более тщательная проверка объекта-владельца, доменное имя и имя владельца отображаются в сертификате как «Тема», зеленая полоса с именем владельца

Процесс, который вы описываете и предлагаете замену, применим только к самому низкому уровню - валидации домена (DV).

DV - это уровень, на котором проверку относительно легко автоматизировать, например, то, что сделали LetsEncrypt, и обеспечивает такой же уровень доверия, какой мог бы обеспечить DNS, если бы он использовался в качестве единственного источника для якоря доверия (последствия для пользовательского интерфейса, сертификат может доверять, но содержать дополнительные данные, которые никоим образом не проверены).

Аутентификация именованных объектов на основе DNS (DANE)

ДЕЙН строится на основе DNSSEC (поскольку аутентичность данных DNS имеет решающее значение) для публикации информации о якоре доверия для клиентов TLS в DNS.

Он использует TLSA Тип RR и может использоваться для идентификации сертификата или открытого ключа (селектор) либо конечного объекта, либо СА, с требованием или без требования обычной проверки цепочки сертификатов для успешного выполнения (использование сертификата) и как данные сертификата / ключа представлены в записи (тип соответствия).

В TLSA имя владельца записи имеет префикс, который указывает порт и протокол (например, _443._tcp), а RData указывает cert usage, selector и matching type режимы в дополнение к данным сертификата / ключа для соответствия. Видеть раздел 2.1 RFC6698 для специфики этих параметров.

А TLSA запись может выглядеть, например, так:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

С режимами использования 2 или 3 (указывает на использование только якоря доверия TLSA), клиент с поддержкой DANE примет сертификат, который не подписан обычно доверяемым ЦС, но который соответствует TLSA запись.
Это концептуально то же самое, что вы предлагаете в своем вопросе.

Уловка? Клиенты, поддерживающие DANE, в настоящее время более или менее отсутствуют, одна из проблем заключается в том, что сам DNSSEC не так широко развернут (особенно проверка на клиентском компьютере), как то, что, вероятно, потребуется для того, чтобы DANE взлетел. Вероятно, это небольшая проблема с курицей и яйцом, учитывая, что DANE - один из первых потенциально больших новых вариантов использования, которые полагаются на аутентифицированные данные DNS.

Eсть плагин для браузера, который добавляет проверку DNSSEC и DANE, кроме этого, на данный момент нет ничего близкого к мейнстриму. И, будучи скорее плагином, чем изначально поддерживаемым, он служит скорее доказательством концепции, чем что-либо еще, когда дело доходит до общего использования.


Это могло быть сделано. Это было рассмотрено. Это все еще могло произойти, но движения не было.