![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Let's Encrypt: грабли
В одной из процедур выпуска сертификатов Let's Encrypt обнаружилась ошибка. Если хостинг позволяет размещение доменов нескольких клиентов на одном IP и позволяет самому клиенту класть сертификаты, то можно было получить сертификат для "соседа" по тому же IP-адресу.
При способе подтверждения TLS-SNI-01 протокола ACME LE выдаёт случайное секретное доменное имя, клиент генерит для него сертификат, LE приходит на указанный IP с использованием SNI и указанием этого имени и проверяет, что сертификат отдаётся с этого IP. После этого выдаётся сертификат на запрошенный клиентом домен.
Функциональность с указанием своих сертификатов есть в стандартной хостинговой панели DirectAdmin, и уже пишут, что у двух крупных хостеров эту операцию можно было провернуть, но вроде бы никто не воспользовался. Протокол TLS-SNI оторвали от греха подальше, а список хостеров собираются составить.
Оригинал новости
Кажется, это первые серьёзные грабли, связанные с LE. При этом на уровне (суб)протокола.
При способе подтверждения TLS-SNI-01 протокола ACME LE выдаёт случайное секретное доменное имя, клиент генерит для него сертификат, LE приходит на указанный IP с использованием SNI и указанием этого имени и проверяет, что сертификат отдаётся с этого IP. После этого выдаётся сертификат на запрошенный клиентом домен.
Функциональность с указанием своих сертификатов есть в стандартной хостинговой панели DirectAdmin, и уже пишут, что у двух крупных хостеров эту операцию можно было провернуть, но вроде бы никто не воспользовался. Протокол TLS-SNI оторвали от греха подальше, а список хостеров собираются составить.
Оригинал новости
Кажется, это первые серьёзные грабли, связанные с LE. При этом на уровне (суб)протокола.
no subject
От какой атаки защищались?
Если проверять, имеет ли клиент возможность задеплоить сертификат на данном домене, то надо ему предложить прописать в сертификат какое-нибудь сильно необязательное поле в сертификат, например pseudonym в Subject-е или какую-нибудь фигню в Subject Alternative Name.
no subject
no subject
Но что они хотят этим проверить?
И почему бы это предписанное acme-сервером значение не пихать в какое-нибудь другое поле сертификата, которое не мешает нормальным операциям SNI?
no subject
Ан нет.
no subject
А если бы они пихали свой challenge в отличное от CN поле subject или custom extension, то можно было бы проконтролирвоать что ты именно на том домене, который надо, можешь сертификаты деплоить.
А вообще самый писк был бы пихать challenge в Issuer. Мол, этот сертификат выпущен специальным подразделением (в смысле OU) letsencrypt, предназначенным для тестирования именно этого домена.
И плевать, что никто кроме самого Let's Encrypt не может этот сертификат валидировать - сам-то let's Encrypt может.
no subject
Я не испытываю желания смотреть, что там в ACME написано в спецификации. То, что там 100+ страниц, меня отпугивает. То есть применительно к TLS 1.3 тоже отпугивает, но там мне в этом ковыряться так или иначе.
no subject
Надо вообще почитать что-нибудь еще про ACME. Я сейчас использую acme-tiny, которая умеет свои challenge только по обычному http отдавать. Поэтому приходится держать кучу лишних виртуальных хостов на 80-м порту, единственное назначение которых - отдавать /.well-known/acme-challenge для соответствующего домена. Хотя, возможно стоило бы их в кучу свалить, описать один virtual host с кучей ServerAlias.