Я только начал использовать Let's Encrypt. Http-01-challenge достаточно прост:
Работает как шарм. Но как они удостоверяются, что я действительно являюсь владельцем example.com, используя небезопасное http-соединение?
Не мог ли какой-нибудь администратор в моем центре обработки данных (или у моего интернет-провайдера) просто запросить сертификат и перехватить http-запросы, которые Let's Enrypt отправляет для проверки личности сервера?
Действительно, для запроса HTTP-01 не существует надежной защиты от атаки «злоумышленник посередине».
Кто-то, кто может перехватывать трафик между узлами проверки Let's Encrypt и вашим сервером, МОЖЕТ пройти проверку и получить сертификат. Если им удастся обмануть BGP, они не обязательно окажутся посередине в обычном понимании.
Это относится к запросу HTTP-01, а для неподписанных доменов также к запросу DNS-01.
Стоит отметить, что эта проблема не является уникальной для Lets Encrypt, проверка, выполняемая традиционными центрами сертификации для сертификатов DV, обычно имеет ту же проблему; они обычно предлагают варианты проверки HTTP, DNS и электронной почты, все из которых подвержены атакам MITM.
какой Давайте зашифровать имеет сделано, чтобы смягчить проблему, заключается в том, чтобы запускать каждую проверку из нескольких тестовых узлов в разных центрах обработки данных, требуя согласования всех результатов тестирования для выдачи сертификата. (Что, как я подозреваю, делает их менее восприимчивыми к этому типу злоупотреблений, чем большинство традиционных центров сертификации.)
Это, по крайней мере, сокращает круг лиц, которые могут находиться в «середине», поскольку большие части «середины» будут отличаться при просмотре с разных тестовых узлов.
Это все о поведении по умолчанию автоматической проверки домена с помощью Let's Encrypt (и центров сертификации в целом), но владельцу домена был предоставлен некоторый дополнительный контроль с требованием, чтобы общедоступные центры сертификации CAA записи.
Чтобы фактически получить контроль, владелец домена может предпринять следующие шаги:
CAA данные не подделываютсяCAA записи для ограничения выдачи сертификатовCAA записи, в которых указывается не только разрешенный ЦС, но и учетная запись с разрешенным ЦС)С CAA запись выглядит примерно так:
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12346789"
проблема значительно уменьшается, поскольку самозванец не может просто инициировать вызов.
Обратите особое внимание на accounturi параметр в CAA data, это то, что делает политику специфичной для учетной записи владельца домена с указанным CA.
А CAA запись, которая указывает только ЦС, но не учетную запись, хотя и действительна, будет иметь ограниченную помощь, поскольку такая политика все же позволяет любому другому клиенту этого ЦС запрашивать выдачу сертификатов.
Обоснование использования http при получении запроса HTTP-01 в спецификации:
Поскольку многие веб-серверы выделяют виртуальный хост HTTPS по умолчанию конкретному пользователю-арендатору с низким уровнем привилегий тонким и неинтуитивным способом, задача должна выполняться через HTTP, а не HTTPS.
Этот вызов отличается от сообщений протокола ACME. Спецификация требует https. ACME также имеет целостность и переиграть защита подписанных сообщений. Даже если трафик был захвачен, его компрометация - это нечто большее, чем просто незашифрованный вызов. Конечно, в этом есть некоторый риск, но какова альтернатива более эффективной процедуре проверки домена?
Более полный подход к отслеживанию несанкционированных сертификатов может включать прозрачность сертификатов. Найдите или настройте оповещения в журналах CT для ваших имен. Сертификат выдачи сертификата, серийный номер и дата должны быть вам знакомы.