?

Log in

No account? Create an account
 
 
23 November 2018 @ 03:50 am
 
Скажите, мне одному кажется, что схема верификации, которую использует LetsEncrypt - это издевательство над логикой?

Работает так:
* клиент хочет сертификат для сайта example.org;
* пускай он разместит нечто по адресу http://example.org/some/path - мы это нечто проверим, и если оно окажется тем, что мы ожидаем увидеть, то это послужит доказательством того, что юзер - законный владелец этого имени хоста и вправе получить на него сертификат.

Но ведь это же абсурд. Сертификат нам затем и нужен, чтобы удостоверять подлинность сайта - как же можно считать обращение к сайту доказательством его подлинности, когда сертификата ещё нет?

Да, они там важно надувают щёки, что дескать все посылаемые значения криптографически заверены - но откуда берётся это доверие изначально, как можно знать, что чувак, зарегистрировавшийся в LetsEncrypt с каким-то там личным ключом и подписавший им это самое нечто, вообще имеет право на этот сайт?

И если ни личный ключ, ни запрос на сайт не доказывают ничего, то как может являться доказательством их гибрид?

Для того, чтобы оценить маразм идеи, достаточно знать следующее: в новой версии Google Sites при создании сайта с custom domain Гугл автоматически выписывает ему сертификат от LetsEncrypt. Автоматически. LetsEncrypt у держателя домена не проверяет ничего. Сразу выдаёт сертификат Гуглу. Всё. Совершенно не нужно ничего понимать в криптографии, чтобы понять, какая это профанация.

Если хостер, то есть мужик, контролирующий трафик к сайту клиента, может получить на него сертификат без всякого действия со стороны владельца имени сайта - то это попросту лишает SSL всякого смысла. Потому что SSL и был придуман, чтобы предотвращать ровно такой вариант - чтобы некий мужик между сайтом и браузером не мог действовать от имени сайта.

Да, более традиционные процедуры domain validation тоже не лишены слабых мест: и создание DNS-записей с рандомальными значениями, и уж тем более получение мейла на адрес вида admin@example.org. Но то, что позволяет LetsEncrypt - это man-in-the-middle как он есть. Это не безопасность, это сапоги всмятку.

Поразительно, сколько админов в Сети радостно пишут: сертификаты! бесплатно! бежим брать! - совершенно не задаваясь вопросом, что именно те сертификаты удостоверяют. Бесплатный сыр удивительно эффективно отключает мозги.
 
 
Current Music: Moonspell - 1755
 
 
 
Виктор "Витус" Вагнерvitus_wagner on November 23rd, 2018 06:35 am (UTC)
Вообще-то dns-spoofing много вероятнее чем перехват траффика.
Поэтому защищаться надо в первую очередь от него.

И сертификат от letsencrypt гарантирует по крайней мере то, что пока пользователь получает этот сертификат, он пришел на тот же сайт, что был. когда letsencrypt валидировал его.

Вообще, конечно, на самом деле весь этот нынешний hype вокруг SSL everywhere - это профанация, и защищает разве что от злых обормотов-провайдеров, которые норовят втыкать рекламу в незащищенный траффик.

Но более высокий уровень защиты и не нужен 90% сайтов.
Кот Муцийcat_mucius on November 23rd, 2018 09:35 pm (UTC)
Вообще-то dns-spoofing много вероятнее чем перехват траффика.
Поэтому защищаться надо в первую очередь от него.


Возможно, он и вероятнее (на самом деле я не знаю - это что, так легко провернуть? как это делается технически?). Но ведь схема "HTTP challenge", которую использует протокол ACME, полагается на DNS не в меньшей мере. Какая разница, будет ли подделан TXT-record, MX или A? К тому же, ACME юзает и более традиционный "DNS challenge".

Во всём, что касается DV-сертификатов, кто DNS контролирует, тот и царь горы; ухищрения LetsEncrypt тут ничего не меняют.

И сертификат от letsencrypt гарантирует по крайней мере то, что пока пользователь получает этот сертификат, он пришел на тот же сайт, что был, когда letsencrypt валидировал его.
Не уверен. Сами LetsEncrypt в своём FAQ пишут вот что:

I successfully renewed a certificate but validation didn’t happen this time - how is that possible?

Once you successfully complete the challenges for a domain, the resulting authorization is cached for your account to use again later. Cached authorizations last for 30 days from the time of validation. If the certificate you requested has all of the necessary authorizations cached then validation will not happen again until the relevant cached authorizations expire.


То есть 30 дней после прохождения "HTTP challenge" можно запрашивать сертификаты на имя сайта (и на сабдомены? не уверен) не проходя повторные челленджи. Затем требуется челлендж повторить. Вопрос: для его повторения нужен тот же account key, что и для предыдущего, или нет?
Если нет, то через месяц после того, как Вася получил сертификат, его интернет-провайдер Петя может элементарно повторить процедуру и получить такой же сам.
Если да, то Вы правы, но тогда:
  • Хостнейм (домен?) получается навеки привязан к определённому юзеру - что, если владелец сайта сменился, а старый свой account key не отдал?
  • Петя может изначально получить сертификат на васин сайт, раз в три месяца его обновлять и перехватывать трафик - а сам Вася может и не подозревать об этом, у него сертификат вообще от GlobalTrust какого-нибудь.

    Вообще, конечно, на самом деле весь этот нынешний hype вокруг SSL everywhere - это профанация, и защищает разве что от злых обормотов-провайдеров, которые норовят втыкать рекламу в незащищенный траффик.
    Ну почему же: пароли открытым текстом не посылаются - уже хлеб.
  • Кот Муцийcat_mucius on November 24th, 2018 12:04 am (UTC)
    Насколько я вижу, ничто не мешает повторять процедуру challenge с новым account key. Хоть через пять минут.
    То есть никакой гарантии, что два сертификата LetsEncrypt на тот же хостнейм выданы тому же человеку, нету.
    Dmitry Belyavsky: Яbeldmit on November 24th, 2018 06:25 am (UTC)
    Нет. Но тут возникает вопрос, кто у нас контролирует домен. В смысле, какое значение мы вкладываем в слово "контролирует". Для второго уровня можно сказать, что это администратор. А дальше?
    Кот Муцийcat_mucius on November 25th, 2018 12:16 am (UTC)
    Ну, поскольку сертификаты перечисляют имена DNS, то логично считать хозяином того, кто может править доменом DNS. Понятно, что хозяева его над-домена могут своей властью злоупотребить *, но это лом, против которого нет приёма. Для того, чтобы этого избежать, надо в деле аутентификации вообще уходить от DNS.

    (* И, кстати, не следует первый уровень сбрасывать со счётов. Мне так думается, если NSA очень понадобится, то они смогут и в TLD пару NS-records для домена второго уровня поправить ненадолго).
    Dmitry Belyavsky: Яbeldmit on November 25th, 2018 08:59 am (UTC)
    Могут, но скандал будет громкий.
    Dmitry Belyavsky: Яbeldmit on November 25th, 2018 09:05 am (UTC)
    Вот тут я писал про тех, кому мы явно или неявно доверяем в Интернете. То есть то, о чём Вы пишете, безусловно верно, но в то же время часть ландшафта.

    Кстати, про сертификаты тоже писал. А выписанный левый сертификат на домен попадёт ещё и в Certificate Transparency, так что бесследно их не выпустить.
    Dmitry Belyavsky: Программизмbeldmit on November 23rd, 2018 01:55 pm (UTC)
    Там немного другая семантика. DV сертификат удостоверяет, что пользователь контролирует домен. Критериев контроля можно предъявить несколько. DNS, хостинг, email-ы специального назначения (root@).
    Кот Муцийcat_mucius on November 23rd, 2018 09:52 pm (UTC)
    Я конкретно про "HTTP challenge". Я думал, что он удостоверяет конкретно хостнеймы сайта, против которого он выполняется. Но возможно, я ошибаюсь.

    Вики пишет так:

    API v1 was released April 12, 2016. It supports issuing certificates for single domains, such as example.com or cluster.example.com.

    То есть речь идёт о хостнеймах, так?

    Дальше:

    A major new requirement in v2 is that requests for wildcard certificates require the modification of a Domain Name Service "TXT" record, verifying control over the domain.

    Выглядит достаточно бессмысленным ставить такое ограничение, если после успешного прохождения "HTTP challenge" против https://example.org можно наштамповать сколько угодно сертификатов на https://sub1.example.org, https://sub2.example.org и так далее, никаких дополнительных проверок не проходя. Почему тогда уже не выдать сразу на https://*.example.org?

    В любом случае, если, скажем, Петя, интернет-провайдер bare domain сайта, принадлежащего Васе, может получить право штамповать сертификаты не только на него, но и на любые другие сайты в васином домене, даже если они размещёны в совсем других сетях и никаких челленджей для них Петя пройти не может - то это делает ситуацию ещё более дикой.

    Edited at 2018-11-23 09:53 pm (UTC)
    Кот Муцийcat_mucius on November 23rd, 2018 10:27 pm (UTC)
    Сейчас почитал, как у них "TLS challenge" работает. Мама дорогая, что за алхимическое очковтирательство. Если милиционер спрашивает у гражданина документы, то пускай гражданин напишет своё имя на бумажке, бумажку сложит вчетверо, попрыгает на одной ножке, потом на другой, потом бумажку вывернет наоборот и отдаст милиционеру. И если на ней будет написано "Вася" - то перед нами точно Вася!
    Кот Муцийcat_mucius on November 23rd, 2018 11:05 pm (UTC)
    Почитал всякое разное (1, 2, 3) - и похоже, я понял правильно и HTTP challenge "удостоверяет" именно хостнейм. Если запрашивается SAN-сертификат, то на каждое имя в нём идёт отдельный HTTP challenge. Если запрашивается wildcard сертификат, то используется DNS challenge.
    Dmitry Belyavsky: Яbeldmit on November 24th, 2018 06:25 am (UTC)
    Да.