Comments 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 такая же здоровая дыра, как и вся идея завязываться на доверие к неким удостоверяющим центрам, но лучше пока нет, а автоматизировать процесс надо, исключая максимально из него человека, особенно владельца сайта. Так как многие владельцы сайтов совсем не специалисты по инф. безу.
Sign up to leave a comment.
Обеспечение автоматизации проверки владения доменом на основе DNS-записей в протоколе ACME [перевод]