Comments 162
ограничение валидации методом dns-01 (который требует внесения изменений в DNS-зону, а не контроля над трафиком)
Это не совсем верно: контроль над трафиком DNS-сервера позволяет "внести" любые изменения в ответы - для клиента это будет эквивалентно внесению изменений в зону. То есть, точка атаки просто переносится на DNS-серверы. UDP даже может быть проще подменить - типа, просто ответить раньше и т.д. (Это всё по модулю DNSSEC, конечно.)
сделало бы атаку значительно сложнее
Насчёт "значительно" - тут как повезёт: точно сложнее было бы в том случае, если авторитативных серверов много, их точки подключения распределены по Интернету, а система УЦ проверяет DNS тоже из нескольких точек и обращаясь ко многим авторитативным серверам. Это не всегда так.
а использование DNSSEC доменом могло бы сделать её вовсе невозможной.
Это при условии, что УЦ корректно проверяет DNSSEC-подписи по всей цепочке. Let's Encrypt, вроде, сейчас проверяют. Однако достаточно найти УЦ, который не проверяет - это позволит "подменить" записи в ответах, перехватив DNS-трафик (см. выше).
Да, но вопрос где находится DNS сервер, трафик которого нужно перехватить
С физическим доступом к трафику
1. [VPS @ Hetzner] -> [Lets encrypt] запрашивает валидацию
2. [Lets encrypt] -> [VPS @ Hetzner] -- подключается к обычным веб портам, ищет токен
То есть валидацию владения легко перехватить, так как трафик приходит прям на сервер.
В случае DNS валидации (с доп проверкой CAA), его как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google
То есть
1. [Какой-то сервер] -> [Lets encrypt] запрашивает валидацию
2. [Lets encrypt] -> [DNS DTLS resolvers: 8.8.8.8, 1.1.1.1, ...] -- идет запрашивать
3. [DNS resolvers] -> [ Authorative DNS ] -- где непосредственно токен-записи лежат для подтверждения владением (или CAA)
2. [Lets encrypt] -> [Какой-то сервер] -- присылает сертификат
Как видно нужно контролировать гораздо больше соединений в разных локациях/ДЦ. А если запрос на сертификат уходит не с [VPS @ Hetzner], а с другого [Какой-то сервер не в hetzner], то вроде как и сам факт запроса неочевидно как отследить.
Другое дело, что если у тебя доступ к Hetzner, странно что они просто в файловую систему VPS не залезли и не забрали сертификат оттуда, пошли каким-то окольным путем. Возможно на это был нужен какой-то отдельный ордер
Да лучше бы он лёг совсем, сейчас каждый хомяк себе ставит этот клаудфлер как важная шишка, в итоге даже для ридонли-сайтов надо сраную капчу вводить. Довели интернет до театра безопасности, граничащего с цирком.
Если на вас часто триггерится защита cloudflare, то, вероятнее всего, пора заканчивать заниматься ботоводством и веб краулингом со своего IP и/или попробовать поменять IP у провайдера.
"Защита" триггерится на противодействие фингерпринтингу браузера и ip датацентра (от своего непубличного vpn). В результате возникает вопрос, а защита ли это или даже наоборот.
Ну вот смотрите: у вас цель - чтобы не составили фингерпинт вашего браузера. А у меня, как у владельца сайта, цель чтобы вы не узнали origin ip моего сервера и не заддосили/похакали меня. С моей точки зрения cloudflare успешно защищает мой сервер.
Да, ценой неудобства таких пользователей как вы, ну а что поделать? Защита от тысяч вредоносных запросов за счет неудобства считаных единиц реальных пользователей.
Ну так вы сами решаете, как "защищать" свой сайт, а я решаю, как на него ходить. Отключать все это ради того, чтобы заработал сайт условного ларька с шаурмой я не буду, просто пойду на сайт соседнего. Разве что не могу не заметить, что я увидел у вас пойнт, предлагающий встать в странную позу перед cf и вашими возможностями по защите своего сайта, причем с аргументом в виде обвинения меня в ботоводтве. А в сухом остатке - защита плохая, если она выкидывает полностью легитимного и незлонамеренного пользователя. О чем, собственно, и статья.
причем с аргументом в виде обвинения меня в ботоводтве
Заметьте - не я на хабре сижу с нескольких аккаунтов. :) Ну это так, в качестве шутки.
Решать действительно вам. Каждая сторона идет на какие-то компромиссы.
P.S. Статья, кстати, вообще о другом.
не я на хабре сижу с нескольких аккаунтов
Опять ищете врагов там, где их нет? Пустое это =)
Статья, кстати, вообще о другом.
Статья о другом, но на уровень понимания выше она о том, что "защита" CF не работает и даже немного вредит. Как и в описанном моём случае. Успехов вам в защите своего сайта (искренне) и понимания, что хорошая защита - это еще и про исключение false positive.
Отключать все это ради того, чтобы заработал сайт условного ларька с шаурмой я не буду, просто пойду на сайт соседнего.
Так и я, как владелец ларька с шаурмой, не буду отказываться от CF. Потому что выбор у меня стоит между "потерять N пользователей, как вы" vs "потерять всех пользователей из-за DDoS, заказанного владельцем соседнего ларька".
Терять вас, конечно, жаль, но терять вообще всех - это намного хуже.
Ну так я никак ни ваше право, ни вашу возможность это делать не отрицаю, и нигде не говорил, что нужно отказаться (хотя и высказываю мысль, что защита должна работать так, чтобы незлонамеренные пользователи ей не отсекались). И даже в каком-то смысле понимаю, поскольку доводилось быть по обе стороны баррикад. Возмутил пойнт про то, что если CF триггерится, то значит клиент - ботовод. А он нет, более того, он пытается защититься уже от владельца сайта, который щедро рассыпал по нему все возможные трекеры. Видимо, отсюда и растет недовольство владельца частью пользователей.
Ну вот смотрите: у вас цель - чтобы не составили фингерпинт вашего браузера. А у меня, как у владельца сайта, цель чтобы вы не узнали origin ip моего сервера и не заддосили/похакали меня. С моей точки зрения cloudflare успешно защищает мой сервер.
Ну, для какого-нибудь популярного ресурса с кучей посетителей ещё можно понять. А обычному сайту-блогу Васи Пупкина зачем всё это? Ну поддосят часок и надоест, не будут же вечно ресурсы на Васю переводить.
он даже на обычный линукс тригерится
Попробуйте настроить, чтобы выходным VPN был WARP. Тогда каптча будет автоматом засчитана.
Разве WARP не основан на Wireguard, который блокируется на уровне большинства провайдеров РФ? Или вы имеете в виду использовать WARP на VPN сервере в дополнение к другому протоколу?
Да лучше бы он лёг совсем
Не переживайте, Роскомнадзор скоро избавит вас от необходимости вводить капчу, ограничив доступ к ресурсам Cloudflare.
яндекс капча больше всех мозги делает + потом на хабре когда иностранный траф/компании колбасит (хром вообще перестал отображать хотя у других recaptcha работает) и давно пора свою иметь + ms упростил свою до падержать палец на кнопке = а cf просто чекапит абонента и давно уже не требует галочку но требует разрешения content в блокерах (там где cfная можно через поисковик заскакивать напрямую без капчи - так ещё и быстрее)
Мне recaptcha сильно надоедает, когда надо лестницы выбирать, пешеходные переходы, мотоциклы и прочее, причём по 2-5 раз! И фиг поймёшь куда кликать - там, где маленькая мотоцикла только виднеется, туда кликать надо или нет? Всё жду когда эту фигню похоронят.
О! Не далее как сегодня сражался с капчей при входе на хабр. Они там совсем озверели (составители этих ребусов). Кстати, когда предлагают 5 штук подряд, это из-за того, что я в предыдущие разы ошибся или просто многослойная защита в надежде, что пользователю надоест?
Это потому, что вы не только капчу решаете, а ещё и их нейросеть обучаете. Абсолютно бесплатно.
У Яндекса самая тупая капча и она срабатывает даже от быстрого открытия ссылок, когда кликаешь средней кнопкой мышки по результатам поиска.
Это ещё что, у меня она на некоторых сайтах уходит в бесконечный цикл.
А у меня вот капча от Cloudflare всегда проходит одним нажатием кнопки. Иногда даже складывается ощущение, будто бы оно ничего и не делает, а просто выжидает. И это при VPN и куче включенных настроек по сопротивлению фингерпринтингу в Firefox. По сравнению с гуглокапчей, где нужно минуту выбирать пешеходные переходы, это выглядит как подарок.
P.S. Аналогично комментарию выше про WARP, рискну предположить, что Cloudflare просто по-разному относится к айпишникам разных VPN-провайдеров.
Вы попробуйте сами поднять сайт сейчас и посмотреть сколько ботов к вам сразу полезет.
в итоге даже для ридонли-сайтов надо сраную капчу вводить
это поведение настраивается
Этот параметр привязывает выдачу сертификатов к конкретному аккаунту в УЦ.
Насколько я помню, в том же Let's Encrypt вся "регистрация" заключалась в предоставлении email. Т.е. аутентификацию аккаунта ему делать тупо нечем - у аккаунтов нет паролей. Я правильно понимаю, что внедрение поддержки accounturi в случае Let's Encrypt потребует:
добавления паролей всем аккаунтам (желающим включить
accounturi)сохранение этого пароля в открытом виде на всех серверах, которым нужно автоматически обновлять сертификаты
реализация механизма передачи и использования этого пароля во всех приложениях, которые умеют автоматически обновлять сертификаты
использование TLS в процессе запроса обновления сертификата (потому что в запросе будет передаваться пароль)
Если всё так, то ничего удивительного в том, что народ не бросился резво это внедрять - нет.
Я не знаю делает ли это сейчас let's encrypt или нет, но достаточно было бы просто при первом обращении на получение сертификата генерировать уникальный ключ, который храниться на сервере, запрашивающем сертификат. Если при повторных попытках выпустить сертификат передаваемый ключ не совпадает - посылать нафиг требуя связаться с указанного email'а с let's encrypt.
Ну, Вы просто заменили в моём комментарии слово "пароль" на слово "ключ" - по сути это же ничего не изменило.
Что до "при первом обращении", то это сработает только для новых доменов, а на старых уже всё настроено, никакие ключи не поддерживает, и если начать требовать ключ то обновление сертификатов просто сломается.
Идентификатор аккаунта можно подсмотреть в файле
/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/xxx/regr.json
Даже для одинакового email на разных серверах будут разные идентификаторы.
Я сейчас почитал про то что такое аккаунт в let's encrypt и оно уже работает так как я предлагал - аккаунт это пара public и private ключей, сгенерированных при регистрации. Email вообще не является обязательной частью аккаунта. Так что привязка accounturi к ID аккаунта - надежно пока с сервера не утечет private ключ от аккаунта.
Мне кажется, что если с сервера утечет private key, то проблема выдачи или не выдачи сертификата будет уже не очень волновать…
Действительно, как и сказал @Heggiключ у аккаунта уже есть, и, насколько я понимаю, активно используется. Так что проблем перечисленных в моём изначальном комментарии сейчас нет - и это отлично!
Правда, куча софта (вроде caddy, traefik, etc.) генерирует собственные аккаунты для автообновления сертификатов, и нужно суметь подсунуть им всем свой аккаунт и ключ. А в остальном вроде проблем нет, подход с accounturi выглядит рабочим и не очень сложным в применении.
Тут я поддерживаю комментаторов - в ACME и так используется ID аккаунта и ключ, который хранится на сервере. Тут, если ломанут сервер, то хотя бы у админа будет шанс об этом узнать через установленные Wazah или OSSEC, либо иные HIDS системы. А когда на твою платформу совершают такую атака, как на джаббер, то тут админ никак не сможет узнать (ну пока не забудут обновить протухший сертификат нападающие).
Насколько помню разбор, в логах сервера был физический down/up сетевого интерфейса на коротенький промежуток. При этом если не ошибаюсь хетцнер пяткой в грудь бил что ничё такого не было. Так что админ при достаточном уровне паранойи всё таки узнает, если захочет)
Вообще формально ничего особо не мешает настроить мониторинг аля zabbix или prometheus, который будет раз в промежуток времени проверять хеши и (или) серийные номера сертификата и в случае изменений бить в набат
Хотя если mitm применяется таргетированно, то там да, не узнаешь
А ещё есть Certificate Transparency (https://crt.sh/) и можно смотреть не выдал ли кто-то левый сертификат на твой домен. Там вроде как без разницы, будет звенеть по самому факту выдачи если УЦ отчитывается или в браузере засветился этот сертификат где-то
Да, я в 2023 году предлагал такое решение (но, там есть нюансы).
Цитата из той статьи
Для проверки выпуска новых сертификатов можно сделать следующее: сначала получить текущую хеш-сумму записей о сертификатах для домена (вместо DOMAIN вставить свое доменное имя). Лучше использовать формат JSON для уменьшения объема получаемых данных.
wget -O DOMAIN -nv "https://crt.sh/?CN=DOMAIN&output=json" 1>&2 2>/dev/null | md5sum DOMAIN >DOMAIN.md5Далее необходимо сравнить значения с эталоном:
wget -O DOMAIN -nv "https://crt.sh/?CN=DOMAIN&output=json" 1>&2 2>/dev/null | md5sum DOMAIN|md5sum -c DOMAIN.md5У этого способа есть нюансы. Во-первых, сервис crt.sh может периодически не работать. Во-вторых, опыт показал, что при выпуске нового сертификата на сайте появляется 2 записи. Сначала появляется запись типа precertificate и только через некоторое время, в дополнение к precertificate, появляется новая запись типа leaf certificate. Возможно, лучшим решением будет независимый мониторинг записей CT Logs.
Ну, и процесс отзыва нелегитимных сертификатов открыт: так и не нашёл готового мануала - просто рекомендация обращаться туда, где серт был выпущен (сколько по времени займёт от запроса до отзыва и какие есть подводные камни - информации не нашёл тогда).
Давно пора эту клаудфлару положить.. Их защиты это попытки переложить проблемы с безопасностью на плечи простого пользователя.. Кстати, многие старые браузеры это просто подвешивает намертво.
Старые браузеры и не должны в интернет выходить.
А защита, в первую очередь, в проксировании. CF единственный имеет бесплатный тариф и стабильно организовывает защиту. На плечи пользователя переходит только капча, но это не злой CF тебе жизнь испортить хочет, а наш злой мир, в котором приходится фильтровать ботов таким образом
это не злой CF тебе жизнь испортить хочет, а
... добрый клаудфларе собирает твои фингерпринты чтобы продать их всем заинтересованым.
Ведь когда ты что-то получаешь бесплатно - то товар теперь ты.
это не злой CF тебе жизнь испортить хочет
У меня на электронной книжке какой-то встроенный браузер, вероятно очередная поделка на хромиуме. В целом работает терпимо, но вот если дело доходит до капчи CF, то может вообще зациклиться (после каждого нажатия "я человек" он думает, и снова показывает капчу). Причём не всегда и перезагрузка книжки спасает, иногда проще отложить её на несколько часов или день, чем пытаться пробиться через капчу. Как по мне - это вполне тянет на "хочет испортить тебе жизнь"!
"У меня на электронной книжке какой-то встроенный браузер"
Следующий уровень жалоб видимо будет "у меня на стиральной машине есть встроенный браузер и на вашем сайте он зависает, безобразие!".
Угу. Но кто же им виноват, что производитель прошивки для читалки не предоставил никакой информации (кроме версии самой прошивки) в доступном пользователю UI? Я даже не уверен, что там в качестве OS - Android, некоторое визуальное сходство есть, но не более того. Можно, конечно, попробовать найти энтузиастов, которые расковыряли официальную прошивку и выяснили что там внутри - но не перебор ли это в рамках багрепорта на капчу CF?
Зачем пользоваться интернет-браузером на устройстве для чтения книг? Если вас так надо сочетать чтение книг и браузинг, то почему не использовать планшет?
Очевидно же, для чтения книг. Не все книжки есть возможность скачать, многое есть только в онлайне. Типичный пример - https://author.today/.
не проще ли будет написать простой скрипт, который будет скачивать с этого сайта книгу и сохранять как epub чем бороться со старым браузером и капчей?
И запускать его каждый день для десятка книг у которых сегодня вышла новая глава? Ну, как бы Вам сказать по-мягче… не-а, не проще!
Да и не такой уж простой этот "скрипт" получится - сайт почти гарантированно препятствует скачиванию тех книг, для которых их авторы официально скачивание запретили. Будет головняк с той же капчей, с рейт-лимитами, с обходом какой-нибудь дополнительной защиты. Последний такой "скрипт", который я видел много лет назад, был написан на .NET (запускать такое в линухе под Mono это отдельное удовольствие) и работал через запуск управляемого браузера (и работал не то, чтобы быстро и стабильно!) - вероятно более простым способом всё это обойти не вышло.
P.S. Я что-то потерял Вашу мысль. Вы что, предлагаете решать проблему мешающей жить капчи CF путём отказа от использования браузера и перехода на скрипты скачивающие сайты для локального просмотра?
CF единственный имеет бесплатный тариф
GCore тоже имеет (до 1 Тб трафика в месяц, чего более чем достаточно для 99% обычных сайтов)
Я всегда побаиваюсь, что при DDoS они этот трафик вычтут, я уйду в жуткие минуса, а мне выставят счёт с 100500 килобаксов.
У меня сложилось впечатление что у GCore все совсем на коленке сделано. Я от них ушел после того как из всех шаблонов виртуалок что у них есть вообще хоть как-то завелась сразу же после создания только виртуалка на какой-то древней убунте. Остальные просто не грузились, либо умирали после перезагрузки.
Ботов надо уничтожать физически и показательно. Вот тогда проблема будет решена
Удивительная компания CloudFlare: много бесплатного дает. И трафик, и защиту, и плюшки. Имхо это один из удачных проектов АНБ
Кстати, об этом уже давно ходят слухи, что там что-то в этом плане может быть зарыто. Об этом писал Хьюго Ландау.
ну так описанное в статье подтверждает - иначе бы их давно блокнули в рф да других странах: а так и нашим и вашим да ещё от пользователей хрум-хрум по прайсу но главное быстро
иначе бы их давно блокнули в рф
Так в РФ их давно уже Роскомпозор старательно ломает и "замедляет", почитайте NTC-форум, там регулярно у людей из самых разных регионов и от самых разных провайдеров отваливается доступ к CF.
иначе бы их давно блокнули в рф
Вы не поверите, но РФ активно этим занимается.
Ну, логика есть, на самом деле. Одни из основных условий реализации качественного бот-детектирования и человек-детектирования — покрытие большого количества интернет-пространства и сбор Big Data для скоринга посетителей. Большое покрытие тяжело сделать, если нет безусловно бесплатного тарифа. Вот и получается, что платные пользователи платят за бесплатных, чтобы у платных всё работало лучше.
вывод, надо переходить на скрепные сервисы... тов. майор пожимает вам руку!
ограничение валидации методом dns-01 (который требует внесения изменений в DNS-зону, а не контроля над трафиком)
Это не совсем верно: контроль над трафиком DNS-сервера позволяет "внести" любые изменения в ответы - для клиента это будет эквивалентно внесению изменений в зону. То есть, точка атаки просто переносится на DNS-серверы. UDP даже может быть проще подменить - типа, просто ответить раньше и т.д. (Это всё по модулю DNSSEC, конечно.)
сделало бы атаку значительно сложнее
Насчёт "значительно" - тут как повезёт: точно сложнее было бы в том случае, если авторитативных серверов много, их точки подключения распределены по Интернету, а система УЦ проверяет DNS тоже из нескольких точек и обращаясь ко многим авторитативным серверам. Это не всегда так.
а использование DNSSEC доменом могло бы сделать её вовсе невозможной.
Это при условии, что УЦ корректно проверяет DNSSEC-подписи по всей цепочке. Let's Encrypt, вроде, сейчас проверяют. Однако достаточно найти УЦ, который не проверяет - это позволит "подменить" записи в ответах, перехватив DNS-трафик (см. выше).
Тут вы хорошо раскрыли темы. Если не ошибаюсь, то в 2020 году только Let's Encrypt начал полностью проверять DNSSEC и там же писали они сами, что некоторые операции не требуют этого делать, однако им был сложно городить логику исключений, да и незачем, поэтому полностью проверяют. А вот остальные УЦ - это большой вопрос. Учитывая их олигапольный статус, вряд ли они каждый день читают всякие RFC и про всякие уязвимости, чтобы обезопасить своих клиентов и себя. Помнится мнения этих ребят смогли изменить совместно только гугл, мозилла и ряд других крупняков.
Если не возражаете, для полноты картины читателям, я бы хотел закрепить ваш комментарий.
Это не совсем верно: контроль над трафиком DNS-сервера позволяет "внести" любые изменения в ответы - для клиента это будет эквивалентно внесению изменений в зону. То есть, точка атаки просто переносится на DNS-серверы. UDP даже может быть проще подменить - типа, просто ответить раньше и т.д. (Это всё по модулю DNSSEC, конечно.)
Но в случае перехвата DNS это надо делать между CA и DNS. (Например между Azure DNS и LE). Как мне кажется это намного сложнее сделать чем перехватить трафик на уровне хостера. Поправьте если не прав
Да, именно так. Запрос CAA записей будет делать именно Letsencrypt.
Но в случае перехвата DNS это надо делать между CA и DNS.
А в случае HTTP - между системами CA и веб-сервером. То есть, с точки зрения подключения, то же самое.
(Например между Azure DNS и LE). Как мне кажется это намного сложнее сделать чем перехватить трафик на уровне хостера.
Так и Azure - это тоже хостер. Пусть, в данном случае, DNS-хостер.
В принципе, для DNS может потребоваться более сложная схема, но вовсе не обязательно она более сложная. Например, в DNS, обычно, несколько узлов (серверов имён) - однако далеко не факт, что сервис проверки DNS УЦ проверяет несколько ответов (от нескольких узлов). В DNS базовый транспорт - UDP. Далеко не факт, что сервис проверки УЦ подключается по TCP (а это, в данном случае, необходимо делать). И т.д., и т.п. Let's Encrypt, например, из-за требований ACME вообще следует CNAME - что, в этом случае, делать нельзя в принципе, так как это сильно увеличивает реальную поверхность атаки.
То есть, у DNS свои особенности, это факт. Я бы считал, что, в целом, универсальный перехват тут действительно сложнее - DNS вообще очень сложная система. Однако сама логика перехвата трафика там та же, как и в HTTP-проверке, только ещё можно перехватывать на уровне других авторитативных серверов и других провайдеров-хостеров (см. рекурсивный опрос и CNAME).
При этом, в теории, HTTP-доступ тоже может оказаться устроен сильно сложнее базового варианта: тоже может быть много узлов, какой-нибудь навороченный anycast с десятком балансировщиков и т.д. Проверяет ли всё это система УЦ? Я бы предположил, что далеко не всегда проверяет.
Let's Encrypt, например, из-за требований ACME вообще следует CNAME - что, в этом случае, делать нельзя в принципе, так как это сильно увеличивает реальную поверхность атаки.
С чего бы? Это такой же ответ сервера как и любой другой. Подмена ответа CNAME ничем не проще подмены любого другого ответа.
С чего бы? Это такой же ответ сервера как и любой другой.
Нет, не такой же. CNAME подразумевает замену имёни и дополнительные запросы. Корректная настройка на стороне зоны - тоже требует усилий.
Но этот CNAME сделан же не просто так. Альтернативой для CNAME будет либо давать доступ к зоне чужим админам, либо настраивать форварды на стороне DNS-сервера. Оба этих варианта не являются более безопасными чем CNAME.
Чтобы разместить CNAME в зоне - тоже нужен доступ. Да, понятно, что после публикации CNAME - "чужие админы" (читай - чужой скрипт с рутовыми правами) могут редактировать только другую зону, соответствующую CNAME. Это безопаснее с точки зрения управления основной зоной в целом. Однако именно редактирование второй, - CNAME, - зоны как раз позволяет проходить проверку и выпускать сертификаты.
При этом настройка CNAME на стороне администратора зоны часто приводит к ошибкам, потому что это самая неочевидная запись DNS. А на стороне системы проверки доменов УЦ - тоже возникает большой риск ошибок, так как CNAME значительно сложнее обрабатывать резолверу.
> Однако сама логика перехвата трафика там та же, как и в HTTP-проверке, только ещё можно перехватывать на уровне других авторитативных серверов и других провайдеров-хостер
Ваши тезисы справедливы, только если DNS сервер для валидации владения находится там же на уязвимом хостинге. Который генерирует трафик, который можно перехватить. Но товарищ выше справедливо писал, что перехватить трафик между LE и каким-нибудь AWS (когда происходит валидация владения с учетом CAA) европейским киберполицейским было бы в тыщу раз сложнее, если не невозможно без зубодробительных процедур.
Ваши тезисы справедливы, только если DNS сервер для валидации владения находится там же на уязвимом хостинге. Который генерирует трафик, который можно перехватить
Ну, это один из способов получения wildcard-сертификатов...
Да, но вопрос где находится DNS сервер, трафик которого нужно перехватить
С физическим доступом к трафику
1. [VPS @ Hetzner] -> [Lets encrypt] запрашивает валидацию
2. [Lets encrypt] -> [VPS @ Hetzner] -- подключается к обычным веб портам, ищет токен
То есть валидацию владения легко перехватить, так как трафик приходит прям на сервер.
В случае DNS валидации (с доп проверкой CAA), его как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google
То есть
1. [Какой-то сервер] -> [Lets encrypt] запрашивает валидацию
2. [Lets encrypt] -> [DNS DTLS resolvers: 8.8.8.8, 1.1.1.1, ...] -- идет запрашивать
3. [DNS resolvers] -> [ Authorative DNS ] -- где непосредственно токен-записи лежат для подтверждения владением (или CAA)
2. [Lets encrypt] -> [Какой-то сервер] -- присылает сертификат
Как видно нужно контролировать гораздо больше соединений в разных локациях/ДЦ. А если запрос на сертификат уходит не с [VPS @ Hetzner], а с другого [Какой-то сервер не в hetzner], то вроде как и сам факт запроса неочевидно как отследить.
Другое дело, что если у тебя доступ к Hetzner, странно что они просто в файловую систему VPS не залезли и не забрали сертификат оттуда, пошли каким-то окольным путем. Возможно на это был нужен какой-то отдельный ордер
Классный коммент - закрепил!
Вот я тоже внизу об этом писал, почему они так всё проверинули, а не тупо бы сливали данные из рам или диска.
почему они так всё проверинули
Этот выбор, как раз, очень логичный: для заворачивания/перехвата трафика есть налаженная и универсальная система, а перехват привязан к не менее универсальному протоколу, не зависит от ПО на сервере.
С другой стороны, выпуск нового сертификата рано или поздно раскроют мониторингом или через CT. А вот если терминировать трафик сертификатом самого же сервера (любезно украденного с ВМ, как предлагают выше), то, чтобы такое запалить, владельцу сайта нужно при мониторинге сверять согласованные ключи соединения как со стороны клиента, так и сервера. Возможно, в редких случаях, такая игра с кражей сертификата стоит свеч.
Это да. Так-то тут вообще можно заморочиться и, если случай достаточно редкий, доставать из дампа памяти VM непосредственно сеансовые ключи, чтобы раскрывать трафик полностью пассивно, без терминирования - тогда уже никакое сравнение ключей не поможет в принципе. Я вот более подробно про это писал, как раз на примере истории с jabber.ru: https://dxdt.ru/2023/11/04/11418/
[Lets encrypt] -> [DNS DTLS resolvers: 8.8.8.8, 1.1.1.1, ...] -- идет запрашивать
У Let's Encrypt должен быть свой резолвер.
Как видно нужно контролировать гораздо больше соединений в разных локациях/ДЦ.
Нет. Достаточно перехватить на этапе обращения к авторитативному серверу. Пункт 3 в вашем списке - "[DNS resolvers] -> [ Authorative DNS ]". Авторитативных серверов может быть несколько, но не факт, что УЦ и опрашивает несколько, сравнивая ответы. Как я и написал выше, если нет DNSSEC, то здесь полностью аналогичная HTTP схема: HTTP-узлов так же может быть несколько, они могут быть "в AWS", "в облаке" и т.д.
(Отмечу ещё раз, что, конечно, проверка через DNS, в целом, это существенно более надёжный вариант. Но для стороны УЦ, а не с точки зрения перехвата на уровне провайдера.)
У Let's Encrypt должен быть свой резолвер.
Вы правы.
Достаточно перехватить на этапе обращения к авторитативному серверу.
Мне кажется мы про разное. Перехватить трафик УЦ на несколько порядков сложнее операционно и техничесски (если вообще возможно) чем у конкретной VPS.
Мне кажется мы про разное.
Возможно.
Перехватить трафик УЦ на несколько порядков сложнее операционно и техничесски (если вообще возможно) чем у конкретной VPS.
Это миф. Нет там какой-то особой защиты. Тем более, если это запросы к DNS. Ну вот работает в конкретной VPS авторитативный сервер DNS - предположим, BIND, или специальный сервер, не важно. Вот приходит к VPS пакет от резолвера УЦ. Это, с сетевой точки зрения, такой же пакет, такой же трафик, как и HTTP не "от УЦ" - у него только номер порта отличается, и, предположим, в HTTP был TCP, а здесь - UDP. Никаких особых методов защиты к "трафику УЦ" не применяется.
Ну вот работает в конкретной VPS авторитативный сервер DNS
Выше я напсиал и выделил как правило -- "В случае DNS валидации (с доп проверкой CAA), его (сервер) как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google".
Сетап когда на VPS еще NS сервера размещают -- очень редок, и я не понимаю зачем это нужно делать вообще говоря в обычной ситуации
Сетап когда на VPS еще NS сервера размещают -- очень редок, и я не понимаю зачем это нужно делать вообще говоря в обычной ситуации
Чтобы получить wildcard-сертификат от LE
Выше я напсиал и выделил как правило -- "В случае DNS валидации (с доп проверкой CAA), его (сервер) как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google".
А тот регистратор и всякие облака - они где держат авторитативные серверы? Ну, хорошо, назовём сервер не VPS, а VM (непосредственно на железе сейчас мало кто держит такое) - сетевая ситуация-то не меняется.
Главный пойнт в том, что одно дело, когда киберполицейским нужно получить доступ только к одному ДЦ (в данном случае Хетцнер в германии), другое дело, когда еще к условно всем 4м, где хостится DNS сервер отвечающий за домен, и не простого васи, а какой-то крупной организации. Задача гораздо сложнее, согласитесь.
Но я предлагаю свернуть дискуссию, мне кажется мы про разное говорим.
Ну, в статье речь про LetsEncrypt, который де-факто стандарт. А он закрывает все из этих проблем: юзает DNSSEC, проверяет все авторитативные NS. Возможно не из нескольких точек, но с DNSSEC это и не нужно.
А он закрывает все из этих проблем
Закрывает, но только для себя, а не для домена. Есть другие УЦ, ключам которых верят браузеры. Валидный сертификат для подмены можно выпустить от любого из них.
Ну, от этого в децентрализованной системе никуда не денешься - всегда будут какие-то маргинальные CA, которые чего-то не поддерживают.
В идеале нужно настраивать мониторинг сертификата своего хоста снаружи: проверку что он выдан правильным CA, что занесён в Certificate Transparency Log и так далее.
Certificate Transparency и прочий мониторинг - это, без сомнения, хорошо и полезно, но работает постфактум и не предотвращает выпуск подменного сертификата и, технически, никак не мешает использованию такого сертификата.
Сейчас вот перейдут на TLS-сертификаты без информации о способе проверки статуса, - то есть, без отзыва, - и даже чисто формальной возможности отозвать неверный сертификат, кроме как через обновление браузера, не останется. А клиенты с доверием TLS-сертификатам - это не только браузеры.
Да, постфактум, но лучше чем ничего. А какие лучше варианты есть с Domain Validation?
Сейчас вот перейдут на TLS-сертификаты без информации о способе проверки статуса
Это о чём речь? Отключение OCSP Stapling? Так Certificate Revocation Lists никуда не уходят вроде бы. Да, проверка CRL во всяких Embedded системах скорее всего никакая, но OCSP Stapling там тем более никогда не было скорее всего.
Да они вообще выпилили OCSP под корень. Технология, призванная убить CRL, сама была убита. Хотя мне нравится OCSP, но только вкупе с stapling. Скорее всего LE решили, что всех не заставить использовать stapling и must-staple, поэтому решили OCSP выпилить. Я как-то давно тестил отозванные сертификаты через CRL на разных браузерах и пришёл к выводу, что не все корректно проверяют отзыв. Сегодня даже не знаю как дела обстоят.
Они убрали OCSP по одной простой причине - оно убивает приватность.
Каждый запрос в OCSP содержит сертификат (и, соответственно, по сути, имя домена в большинстве случаев) хоста, куда клиент подключается. И с какого адреса.
А в остальном-то технология отличная, спору нет, лучше этих непонятных списков. Могли бы оставить её в режиме только Must-Staple.
А в остальном-то технология отличная
Мягко говоря, OCSP - не очень хороший протокол, и так себе технология. Про "приватность" - это верно, но вовсе не является критически важным моментом для УЦ. Причина отказа со стороны УЦ в том, что наслаивается огромная куча проблем с поддержкой высоконагруженного транзакционного онлайн-сервиса, который, при разумном использовании, оказывается блокирующим для клиентов, проверяющих сертификаты. И представьте, что нужно выпускать миллионы сертификатов в месяц.
OCSP как раз правильно, что убрали. Насчёт CRL - вопрос спорный, но что уж поделать.
В режиме Must-Staple нагрузка на их резолвер становится почти никакой.
OCSP Staple валидно, насколько я помню, в течении нескольких дней, так что в худшем случае на один сертификат будет перезапрашивать его пару раз в день.
И никакой блокировки для клиентов в итоге - вся проверка идёт локально.
Но быстро отозвать сертификат тоже не получится, хотя в случае с CRL то же самое - они тоже кешируются.
В режиме Must-Staple нагрузка на их резолвер становится почти никакой.
Это если считать, что весь трафик - строго штатный. К сожалению, в интернетах это не так. При этом stapling никак не отменяет требований по доступности OCSP-респондера: респондер всё равно должен быть выставлен наружу и быть готов обсуживать огромный поток запросов - иначе начнёт отваливаться и stapling.
Вообще, там всё несколько сложнее. Балансировка нагрузки с HTTP (например) - это только одна часть. Но для того, чтобы поддерживать OCSP-респондер, нужно ещё вести внутри УЦ большую базу актуальных статусов сертификатов - не так, как с CRL. Эта база активно раздувается, что, однако, не должно мешать успешной привязке к респондеру. Ответы респондера - нужно подписывать (не так, как CRL), а для этого требуется организовать более или менее безопасную работу с ключами. В практике УЦ - это всё очень затратные и сложные, с инженерной точки зрения, операции и процессы.
И никакой блокировки для клиентов в итоге - вся проверка идёт локально.
Это верно, но только если у сервера всё ещё есть валидный OCSP-ответ, то да. Если OCSP-респондер упал, то уже нет. Когда УЦ обслуживает сотни миллионов сайтов - сложно угадать, в какой момент какой сервер придёт за OCSP-ответом.
Там решение было принято абсолютным большинством голосов, против всего один голос. Как-то странно обвинять во всём LE...
Так Certificate Revocation Lists никуда не уходят вроде бы
Уходит всё вместе, и CRL тоже. Отзыв в браузерах давно не работает фактически, а со сверхкороткими сертификатами - официально убирают совсем: "Our six-day certificates will not include OCSP or CRL URLs". В требованиях CA/B-форума - тоже достаточно давно убрали.
Ну, для шестидневных сертификатов, может, и действительно нет особенного смысла в CRL.
Но тут, конечно, как всегда вопрос баланса безопасности и сложности...
Но тут, конечно, как всегда вопрос баланса безопасности и сложности
Да. И пока все обсуждают "сверхразумный ИИ" - TLS-сертфикаты для веба, ловким движением, превращаются в безотзывные короткоживущие токены, типа Kerberos, только в другую сторону: чтобы к вашему ресурсу было разрешено подключаться клиентам - нужно в онлайн-режиме серверу получать подтверждающий токен в центре сертификации.
https://habr.com/ru/posts/900692/
В других ветках обсуждают технологию DANE. Имхо, было бы круто, если бы УЦ ушли в закат, а мы бы смогли выпускать самоподписанные сертификаты с пропиской открытого ключа в DNS, а DNS защищать DNSSEC. Тогда бы решилась проблема, для который был разработан certificate pinning в своё время, да и проблемы, для которых были разработаны CRL и OCSP. Но олигаполия УЦ и Гугл решили по-другому.
В других ветках обсуждают технологию DANE.
Да, с DANE не сложилось - заменили на Certificate Transparency. (Кстати, единственный способ, который мог бы как-то заметно повлиять на исходную ситуацию с подменой сертификата - это сравнение отпечатков ключей клиентом.)
DANE это перекладывание проблем с больной головы на здоровую. Фактически он предлагает параллельно строить ещё одну сеть доверия, причём на базе технологии которая для этого изначально не была предназначена.
Фактически он предлагает параллельно строить ещё одну сеть доверия
Так DNS уже построена. DANE - базируется на DNS. DANE вообще весьма хорошая, архитектурно, технология. Такое редко встречается в этих интернетах.
причём на базе технологии которая для этого изначально не была предназначена.
DNS - это распределённая БД, хранить там, вообще говоря, позволяется что угодно. Есть SSHFP и пр., скажем. Относительно новая часть, необходимая для DANE - DNSSEC - это да, это такая хрупкая пристройка-надстройка. Но, всё ж, она и предложена-то, буквально, для того, чтобы удостоверять значение записей. Другое дело, что с DNS и DNSSEC сейчас не очень понятно, что станет: система эта централизованная, там один корень.
Так DNS уже построена. DANE - базируется на DNS
тролейбус-из-буханки.жпг
Есть SSHFP
Можно пытаться положить больше разных яиц в одну корзину. Конечно это не сделает корзину надёжнее, но фейлы будут эпичнее. В этом смысл?
Говоря о безопасности стоит думать не про фичи, а про векторы атак и риски.
с DNS и DNSSEC сейчас не очень понятно, что станет: система эта централизованная, там один корень
Там кроме этого проблем выше крыши, by design. Начиная с банальной подверженности amplification of DDOS attack и возможностями для раскрытия данных. Вплодь до заморочек с отзывом скомпрометированных ключей. Даже штатная ротация уже квест на ровном месте. Это для подобных систем вообще как бы база.
Я думаю, если DNSSEC вдруг и взлетит, то лишь в виде интегрированных сервисов под управлением корпорациями типа CloudFront или Let's Encrypt, со всеми вытекающими последствиями.
В случае CF покупается ACM за небольшие деньги, делается только свое СА доверенным, и эти сертификаты используются на origin-е
Ставить суверенный корневой сертификат небезопасно говорили они. Забывая, что если будет необходимость, они получат любой сертификат и если нужно перенаправят трафик через свои *DPI
Для пользователей
4. Отслеживать выпуск сертификатов для своего домена, тем более если он потенциально интересен злоумышленникам.
Кто хостит сервера в Сибири, у вас Cloudflare работает?
Зайти на чужие сайты с cloudflare я могу, а на свой же домашний сервер, проксированный через cloudflare, не получается, доходят только сообщения с content-type text/html. Изображения, css, js, grpc, ничего из этого не доходит. Я отключал все оптимизации в cloudflare, также отключал ECH, TLS 1.3, QUIP, и всё равно не работает. С ПНВ всё работает
Блокируется вроде именно cloudflare.com и побочные. Но не везде, не всегда, дырявые какие-то у ркн ограничения.
Если ваши пользователи живут в РФ, вам стоит отказаться от использования Cloudflare. Роскомнадзор его активно блокирует на уровне некоторых провайдеров/регионов и будет продолжать делать это дальше, расширяя географию блокировок. Видел недавно статистику запросов к кф, снижение в два раза (вроде как за пару недель июня)
Что-то все тут радостно обсуждают сертификаты и никто не заметил слона. А вот и он: Cloudflare для работы нужен корректный сертификат для вашего домена. Они для того и добавляют эти CAA записи, чтобы получить сертификат, и нет никакого смысла добавлять в эти записи идентификатор вашего аккаунта - это сломает Cloudflare. Единственное что тут можно сделать - это добавить в эти записи аккаунт Cloudflare.
Если вы используете Universal SSL от Cloudflare, знайте, что вы уязвимы для атак типа jabber.ru.
Нет. Уязвим (возможно) сам Cloudflare в целом, но успешная атака на Cloudflare затронет столько сайтов, что рассматривать её как личную проблему глупо.
Связь от Cloudflare до вашего сервера защищена уж точно не тем сертификатом, который выписан основному домену.
Рассмотрите альтернативы. Для критически важных проектов, возможно, стоит отказаться от Universal SSL в пользу ручного управления сертификатами и полного контроля над CAA-записями либо в Cloudflare, либо в другом сервисе.
Чушь, любые сертификаты, как бы вы ими не управляли, всё равно останутся сертификатами Cloudflare, а не вашими. Если проект и правда настолько критически важен, что ему требуются подобные меры защиты - в первую очередь следует отказаться от слушающего ваш трафик Cloudflare.
Что должен сделать Cloudflare: [...] Обеспечить полное управление CAA-записями для пользователей, чтобы они могли добавлять свои собственные записи с accounturi и validationmethods, и чтобы эти записи корректно сосуществовали с записями Cloudflare.
Они не могут так сделать, потому что это помешает им самим получить сертификат.
На самом деле, автор RFC 8657 продумал и этот момент. В зону можно разместить запись с accounturi с двумя и более ID аккаунтов, то есть можно указать и ID Cloudflare, и пользователя, что очень удобно.
Связь от Cloudflare до вашего сервера защищена уж точно не тем сертификатом, который выписан основному домену.
Тут тоже у всех по-разному. Это может быть как самоподписанный сертификат CF, так и действительный сертификат домена, так и туннель cloudflared.
Если проект и правда настолько критически важен, что ему требуются подобные меры защиты - в первую очередь следует отказаться от слушающего ваш трафик Cloudflare.
Тут больше о модели угроз того, чей сайт. Если он опасается правительственного актора Х, а cloudflare сотрудничает с акторами A, B, C, то можно и не отказываться от CF, тем более что актор Х может прибегнуть, помимо трюка с сертификатом, к атаке ботов, различным типам DDoS, от который халявно и на высоком уровне защитить CF. Типа если не перехватить контроль, то положить сат хотя бы.
у джаббера, сейчас, много активых пользователей?
а то конкретно пользуется? какие слои населения?
когда-то давно, кто-то из знакомых, написал мне, через fido, мол аська - не модно, модно - джаббер, не объяснив, зачем мне туда переходить.
Ну вот кто в то время перешёл туда - те и пользуются. Главным достоинством протокола является его живучесть - просто вспомните сколько альтернатив успело появиться и закрыться пока джаббер просто существовал. Правда, всё остальное у него - сплошные недостатки, начиная от переусложнённого протокола, и заканчивая кучей несовместимых стандартов одного и того же.
я не зря аську вспомнил. по массовости, её сложно было переплюнуть, и, не смотря на кучу недостатков, именно по её протоколу общалось большинство популярных клиентов. потом, большинство перешло на какой-нибудь вотсап. джаббер так и остался "для избранных".
всё сказанное, конечно, не отменяет того факта, что мессенджеры, в целом, скорее вредны.
QIP в своё время как раз на джаббер и перетаскивал пользователей. Автоматом заводил учетки uin@qip.ru с паролем как у аськи и 2 пользователя QIP между собой фактически начинали общаться по джабберу, а не по ICQ.
я помню. получалось два списка пользователей. как ни странно, асечники проявляли большую активность. (ну и где теперь этот qip.ru с почной, которая не вся доехала до яндекса?)
Не всем зашел Qip Infinum (в котором как раз джаббер добавили). Не многие были вообще в курсе, что там не только аська в клиенте есть, но и всякие майл агенты (там емнип был весьма приличный список поддерживаемых протоколов).
А сдох квип, кмк, из-за смерти аськи и появлению альтернативы - телеги. Он оказался просто никому не нужен, хотя как джаббер клиент был один из лучших.
Я лично с аськи перешел в телегу (и перетащил большинство контактов), когда аська очередной раз сменила протокол, а квип что-то тормозил с апдейтом.
Смерти джаббера сильно поспособствовал гугол со своим gtalk. Они поддержали протокол, перетащили на свой мессенджер пользователей, а потом свернули лавочку.
EEE: embrace, extend, and extinguish. Рабочая стратегия.
смерть джаббера произошла, как же как скайпа и остальных, из-за отсуствия привязки к номеру мобильного. Если для ватсапа/телеги обычный человек просто выбирал номер из контакта и мог начать общаться, то тут нужен был email, какие-то сервера и прочай чушь, с которой никто не хотел разбираться.
Речь про середину-конец нулевых, какие номера телефонов? Мессенджерами люди с компа пользовались.
Джаббер в середине нулевых был вполне себе жив. А вот когда траффик с мобильных устройств сравнялся с траффиком pc, тогда конец джаббера, icq, skype и прочих и настал
Корреляция не обязательно означает наличие причинно-следственной связи. Использование номера телефона в качестве ID - крайне неудачное для пользователя решение. Именно поэтому та же телега позволяет скрывать номер.
мессенджеры, в целом, скорее вредны.
А телеграф вреден? Почтовые голуби? Письменость в целом?
письменность - это электронная почта. мессенджеры - "общение" при помощи смайликов, эмодзи, мемов и междометий.
Почему вы проецируете собственный опыт на всех?
почему вы пытаетесь меня подколоть, не разобравшись в ситуации?
в какой ситуации, в которой вы лично используете мессенджеры исключительно для отправки смайликов, эмодзи, мемов и междометий и по-этому считаете что мессенджеры вредны?
В корпоративной среде бывает используется Cisco Jabber там где используется телефония от Cisco. Официальный клиент дрянь та еще, а сторонние у меня не завелись, но протокол там чисто Jabber'овский должен быть.
Если трафик от клиентов идет через третье лицо - он может быть прочтен/модифицирован.
Вся прочая лирика про надежную компанию/нет оснований не доверять - не несут смысловой нагрузки. Обсуждать защиту от MITM в схеме, когда вы собственноручно в середину трафика запихнули "доверенное" лицо, которое предоставляет услуги "бесплатно" - забавно.
На самом деле предложения по расширению CAA это скорее цирк с конями, есть DANE которому уже много больше 10 лет - в DNS сразу размещается публичный ключ и CA становятся в принципе лишними.
Пока упирается все в DNSSEC, с ним много проблем и мало кто хочет его поддерживать. И CA не очень хотят становиться лишними.
А ведь когда-то можно было получить SSL сертификат на ТРИ года (может раньше и ещё больше)! Такое не в тягость было вручную сделать, и за деньги (понятно, за что платишь).
Но под девизом «Небезопасно! Мы лучше знаем, как лучше для вас!» максимальный срок жизни пользовательских сертификатов всё урезали, сейчас год и возможно ещё сократят, разницы с Let's Encrypt всё меньше — вот и начинаются обновления на автомате и много всяких нежданчиков в результате.
Спасибо, что обратили внимание на RFC 8657, как-то мимо меня он прошёл. Попробую на своих доменах (где LE сертификаты) поставить IN CAA запись, да ещё и добавить IN CAA 0 iodef "mailto:certadm@my.doma.in", может LE туда предупреждение пришлёт в случае чего.
Были предложения до 6 дней сократить! Ну, тут только ACME будет работать на обновление сертификатов.
Когда убрали EV отметку в браузерах, то тоже непонятно зачем брать EV сертификаты. Правда я как-то получал на компанию EV code signing от Sectigo. Блин, там просто надо было предоставить документы о компании и взять трубку на корп. телефон по месту офиц. регистрации. Реально ли проверяли эти документы - одному Sectigo известно.
А по iodef - уже как года 2 у меня стоит на домене и ни разу не получал письмо от УЦ. Но может я никому и не нужен.
А так, всегда пожалуйста :)
РКН уже давно блочит эту шляпу (кф), и не зря, получается. Плюс в нем (кф) есть огромная проблема: он контролирует огромную часть интернета, и когда падает кф, падает вообще всё. Нужно решать эту проблему.
КФ не является чем-то уникальным, если другие провайдеры, от GCore до, например, curator.pro, через который тот же хабр работает. Как вы со всеми такими сервисами бороться предлагаете - может быть вы готовы лично каждому желающему оплатить пару миллионов долларов для построения собственной системы CDN и DDOS-protection?
Дыра в щите Cloudflare: как атака на Jabber.ru вскрыла проблему, о которой молчат c 2023