Комментарии 11
Можно было бы держать в DNS открытый ключ, по ACME получать токен, шифровать закрытым ключом и отсылать на сервер, там это расшифровывается обратно открытым ключом и сверяется с отправленным токеном. Что-то в духе ЭЦП, и никаких «учётных данный с правом на правку DNS».
Или перефразируя вас подписывать своим закрытым ключом для DNSSEC и отправлять запись. А открытым потом верифицировать.
Суть в том, что на DNS-сервере находится неизменяемая публичная часть данных для процесса криптографической верификации. А неизменяемая приватная часть находится на оборудовании лица, запрашивающего сертификат. Шифровать запрошенный токен закрытым ключом перед отсылкой обратно можно любым удобным способом, не ограничиваемым никакими API провайдеров услуг. Хотя, с другой стороны, вносится вопрос доверия криптостойкости публичного ключа.
Вы просто своими словами описываете работу dnssec.
Насколько я (в общих чертах) понимаю, DNSSEC — это про верификацию того, что публично доступно через DNS (т. е. записей). Поэтому, с моей точки зрения, верификация того, что является частью приватного обмена данными между провайдером сертификатов и клиентом (токена), отличается. В любом случае, неважно, как это называется. Вопрос в том, зачем нужна пляска с одноразовыми DNS-записями, если можно однократно прописать где надо пару ключей и спокойно генерировать по ним подтверждающие ответы.
У dnssec есть открытый и закрытые ключи, закрытые хранятся на сервере где установлен сервис dns для подписи отдаваемых данных. Открытые ключи находятся в записях dns. Вот краткое описание для лучшего понимания работы технологии.
Не совсем понимаю, как DNSSEC может быть использован для верификации на основе присылаемого токена без модификации DNS-записей.
У вас в днс уже есть публичный ключ при использовании dnssec. Вам просто надо подписать токен своим закрытым ключём для dnssec.
Т. е., как я понимаю, в данном решении протокол DNS используется только для получения публичного ключа, а единственная связь с DNSSEC в том, что используется его закрытый ключ, так как пара открытый–закрытый уже есть, почему бы не использовать их. Это не выглядит как DNSSEC; к тому же, домены без поддержки DNSSEC остаются не у дел.
То, о чём говорю я — DNS можно держать хоть у хостера, с открытым ключом в записи, выделенной под нужды ACME; а закрытый ключ может лежать в офисе, и процесс верификации не требует никакого нетипичного взаимодействия с DNS-сервером. Токен подписывает ACME-клиент или вспомогательный скрипт (в зависимости от требований безопасности).
То, о чём говорю я — DNS можно держать хоть у хостера, с открытым ключом в записи, выделенной под нужды ACME; а закрытый ключ может лежать в офисе, и процесс верификации не требует никакого нетипичного взаимодействия с DNS-сервером. Токен подписывает ACME-клиент или вспомогательный скрипт (в зависимости от требований безопасности).
Думается ACME для DNS, это уже дырочка в безопасности. Подтверждение на базе DNS это не путь к автоматизации, нечего по днс шарится никому.
DNS нынешняя сама по себе дырочка в безопасности, хотя бы из-за того что очень сильна зависимость от регистратора, PKI такая же здоровая дыра, как и вся идея завязываться на доверие к неким удостоверяющим центрам, но лучше пока нет, а автоматизировать процесс надо, исключая максимально из него человека, особенно владельца сайта. Так как многие владельцы сайтов совсем не специалисты по инф. безу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обеспечение автоматизации проверки владения доменом на основе DNS-записей в протоколе ACME [перевод]