Большинство недорогих поставщиков сертификатов SSL действительно только проверяют, что вы контролируете доменное имя. Почему бы не «подписать» сертификат в DNS для этих типов сертификатов, вместо того, чтобы платить третьей стороне за проверку того, что я контролирую записи DNS для домена? Если я сгенерирую пару ключей на сервере и опубликую тот же открытый ключ в DNS для имени хоста, я бы подумал, что это будет эквивалентный уровень безопасности.
Я вижу две проблемы с дизайном, но обе кажутся минимальными:
Я не знаю ни одного браузера, реализующего что-то подобное, но похоже, что это был бы хороший способ получить хотя бы надежное зашифрованное соединение без отображения ужасного диалогового окна «Недоверенный сертификат». Помимо проблем, которые я отметил выше, и существующих коммерческих сертификационных органов, выступающих против этой идеи, есть ли другие причины, по которым это было бы плохой идеей?
Уже сейчас вполне возможно закодировать сертификат X.509 внутри записи DNS - посмотрите на CERT тип записи из RFC 4398.
Основная причина, по которой это не делается в гневе, заключается в том, что транспортный механизм еще не защищен. Это кардинально изменится позже в этом году, когда корневая зона получит подпись DNSSEC и все больше и больше TLD будут поддерживать DNSSEC.
Размер DNS-запроса (как упоминалось в другом месте) также вызывает беспокойство, хотя стоит отметить, что CERT RR также позволяет просто сохранить URL-адрес, с которого можно загрузить настоящий сертификат X.509. Но тут есть что-то вроде проблемы с курицей и яйцом ...
С тех пор, как я задал этот вопрос много лет назад, произошли некоторые позитивные сдвиги в реализации этого вопроса. Сочетание DNSSEC для защиты вашего DNS с опубликованными сертификатами TLS в DNS позволяет достичь этой цели. Google Chrome уже некоторое время поддерживает сертификаты с прошивкой DNSSEC., и сейчас RFC6698 Аутентификация именованных объектов на основе DNS (DANE) это попытка стандартизировать эту поддержку.
Пройдет еще несколько лет, прежде чем эта поддержка станет широко распространенной в браузерах, но я с нетерпением жду этого.
SSL-сертификаты должны проверять подлинность сайта, чтобы конечный пользователь мог быть уверен, что его запрос не был перенаправлен зараженным DNS-сервером, поддельной трансляцией BGP или другим грязным трюком, который также позволяет получать поддельный сертификат от DNS выглядеть валидным.
Я говорю «должен», потому что тогда все было разбавлено «мгновенными» сертификатами, которые ничего конкретного не доказывают, и, честно говоря, я думаю, что производители браузеров должны либо отображать предупреждение «ненадежный сертификат» для всех неаудированных сертификатов, либо разрешить самоподписанные сертификаты без запроса. Статус-кво непостоянен.
Отсутствие стандартизации и дополнительные накладные расходы на управление (гораздо проще просто сбросить ключ / сертификат на машине, чем также добавить ключ - который, вероятно, будет довольно длинным и, следовательно, будет противоречить пределу пакетов UDP). вещи, которые убивают это с практической точки зрения. Отсутствие защищенного DNS вызывает некоторое беспокойство, но для малоценных целей это не совсем практическое снижение безопасности. Однако для внутренних служб мы просто импортируем наш собственный сертификат ЦС, чтобы вы на самом деле ничего там не получали, и любой общедоступный сайт, который потребности SSL в любом случае понадобится «настоящий» сертификат.
Я бы ожидал увидеть массовую реакцию и FUD со стороны поставщиков коммерческих сертификатов, если бы что-то вроде этого было серьезно продвинуто (проекты RFC, эталонные реализации и т. Д.) - как любой паразит, они ужасно раздражаются, когда их дойная корова выглядит так могут быть зарезаны.
Может быть, лучше все упростить - то есть не заставлять DNS делать больше, чем предполагается. Я с осторожностью отношусь к добавлению чего-либо, особенно когда речь идет о безопасности. Иногда лучше меньше, да лучше. Основная причина моего мышления заключается в том, что DNS и SSL не находятся в одном домене и не имеют одинаковых функций и целей.