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


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

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

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

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

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

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

Jelmer


16
2018-03-05 13:19


Источник


Соответствующий: tools.ietf.org/html/rfc6698 - Håkan Lindqvist
Спасибо, Хокан! Через обновление я нашел термин DANE для этого RFC. Последняя версия RFC: tools.ietf.org/html/rfc7671  Смотрите также: en.wikipedia.org/wiki/... (Я прочитаю его позже). - Jelmer Jellema
«Почему нет» также рассматривается в связанном RFC Håkan: без DNSSEC надежность всей модели скомпрометирована из-за уязвимостей, присущих DNS. Следует также отметить, что DNSSEC ничего не делает для обеспечения трафика между клиентами и рекурсивными системами, которые по-прежнему уязвимы для человека в середине спуфинга. - Andrew B
Эндрю, я вижу проблему с DNSSEC и MIDM, когда DNSSEC не принудительно для домена, а принудительное выполнение может быть выполнено только в том случае, если каждый поиск выполняется путем проверки сервера корневого домена для tld. Таким образом, проблема заключается в следующем: мы хотим разрешить использование какого-либо DV-сертификата, имея статус владельца, это его действительность, но мы не можем доверять DNS из-за его иерархического характера. Тот факт, что DNS является общедоступным для подделки и MIDM-атак, делает сертификаты DV похожими на внешнюю проверку записи домена. Хм, я буду продолжать думать ... - Jelmer Jellema
Crossdupe security.stackexchange.com/questions/68504/... (2014) security.stackexchange.com/questions/23648/... (2012) security.stackexchange.com/questions/6824/... (2011) - dave_thompson_085


Ответы:


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

Принятие

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

Worldwide TLSA Deployment between June 17

Для сравнения, согласно 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? На данный момент не в общем Интернете. Если вы управляете сервером и клиентом, возможно, его вариант, но в этом случае вы можете часто использовать Open-Key Pinning.

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


18
2018-03-05 17:04



Я думаю, что ваше последнее предложение было отрезано. - 8bittree
Спасибо Себастьян, ваша реакция очень полезна. Пожалуйста, см. Комментарии моего и Андрея под OP. - Jelmer Jellema
Почему веб-серверам необходимо это реализовать? Я мог бы добавить самоподписанный сертификат в конфигурацию apache и поместить отпечаток пальца в DNS сам, правильно? - Jelmer Jellema
Существуют также проблемы с производительностью и масштабируемостью с DNSSEC и DNS: простой DNS может использовать «консервированные» ответы, но DNSSEC должен выполнять криптодацию для каждого запроса, и есть много запросов DNS, которые летают. Подобно, много запросов DNS. - Joker_vD
@Joker_vD DNSSEC подписывает данные, а не трафик. То есть, на авторитетном конце вы можете подписать свою зону и не иметь больше «криптодиагностики» для жизни подписей (или пока вы не измените данные зон); на стороне валидатора (на стороне клиента) должно выполняться «криптодиагностика» с незащищенным запросом. Как дополнительные данные, так и статус DNSSEC соответствуют общей модели кэширования для DNS. - Håkan Lindqvist


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

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

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

Процесс, который вы описываете, и предлагаете замену, применяется только к самому низкому уровню, Domain Validation (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, кроме того, что на данный момент там не так много, что близко к мейнстриму. И, будучи плагином, а не поддерживаемым изначально, он служит скорее доказательством концепции, чем чем-либо еще, когда дело доходит до общего использования.


Это можно сделать. Это было рассмотрено. Это все равно может случиться, но движения не было.


5
2018-03-05 16:05



Спасибо, Хокан. Как указывает Эндрю в моем OP, есть проблема с DNS и DNSSEC, поскольку DNSSEC не принудительно (даже если ключи находятся на месте DNS-DNS, я думаю) DNS-серверы на этом пути могут обмануть информацию DANE , правильно? Поэтому DNSSEC должен быть обязан для записей DANE быть действительными, что, в свою очередь, означает, что каждая проверка также должна проверять ключи на сервере TLD. - Jelmer Jellema
@JelmerJellema Как я уже отмечал в своем ответе, DNSSEC нуждается в проверке на клиенте (это не проблема, о чем указывал Андрей) и могут быть успешно использованы только подтвержденные подписанные записи TLSA. Эта проблема, о которой вы говорите, не является проблемой с точки зрения дизайна, это проблема с точки зрения поддержки основного программного обеспечения. - Håkan Lindqvist
Хотя они не идеальны, все больше и больше рекурсивных серверов имен в интернет-провайдерах или открытых, например 8.8.8.8 или 9.9.9.9, выполняют проверку DNSSEC. dnssec-trigger, построенный на несвязанных и / или таких вещах, как stubby, позволит иметь полную проверку DNSSEC на клиентах, не обязательно полностью проверять DNS-решение на клиенте. Но мы действительно далеки от этого ... - Patrick Mevzek