Почти любой взлом компании, о котором потом пишут в новостях, начинается не с хитрой атаки, а с какой‑нибудь ерунды. Забыли настроить почту. Не обновляли библиотеку на сайте лет десять. Удалили сервер, а запись в DNS оставили. Ломать ничего не надо: дверь уже открыта, нужно только её найти.
В прошлой статье я проверил 50 сайтов на зависимость от иностранных сервисов. С тех пор утилита научилась проверять почту, 152-ФЗ и безопасность, и я решил посмотреть шире: прогнал через неё 284 сайта крупных российских компаний. Банки, магазины, вузы, клиники, застройщики, медиа, госсайты.
Спойлер: у каждого четвёртого сайта можно отправить письмо от имени компании так, что оно придёт во «Входящие». У каждого четвёртого на страницах висят библиотеки с известными уязвимостями. Половина сайтов отдаёт ваш IP иностранным сервисам, как только вы открыли страницу, хотя в политике у многих написано, что ничего никуда не передаётся. А госсайты, на которые я рассчитывал как на пример строгости, оказались не лучше остальных.
Названия компаний, как и в прошлый раз, приводить не буду. Проверка автоматическая и может ошибаться, и цель не в том, чтобы кого‑то пристыдить.
Зачем это вообще кому‑то нужно
Если вы владелец сайта, то самый понятный аргумент - штрафы. Почти всё, что нашлось по 152-ФЗ, ложится на конкретные статьи КоАП. Для юрлица выходит примерно так:
Нарушение |
Статья |
Штраф |
|---|---|---|
нет опубликованной политики обработки ПДн |
13.11 ч. 3 |
30–60 тыс. ₽ |
обработка без нужного согласия |
13.11 ч. 1 |
150–300 тыс. ₽, повторно до 500 тыс. |
не уведомили Роскомнадзор об обработке |
13.11 ч. 10 |
100–300 тыс. ₽ |
данные россиян хранятся не в России |
13.11 ч. 8 |
1–6 млн ₽, повторно до 18 млн |
Если вы посетитель, то вас это касается ещё сильнее, просто вы об этом не знаете. Поддельное письмо от вашего банка с его настоящим адресом, фальшивая страница на настоящем поддомене магазина, перехваченный вход в личный кабинет через Wi‑Fi в кафе. Пострадает не компания, а вы.
И что обидно, почти ничего из этого не стоит денег. Большинство проблем закрывается одной строчкой в DNS или в конфиге nginx. Их просто никто не ищет: проверять всё руками долго и скучно.
Письмо «от банка», которое отправил не банк
Начну с почты, потому что это касается вообще всех.
Когда вам приходит письмо от support@bank.ru, почтовый сервис понятия не имеет, правда ли его отправил банк. Поэтому он идёт в DNS банка и смотрит две записи. SPF говорит, каким серверам можно отправлять почту от имени домена. DMARC говорит, что делать, если письмо пришло с чужого сервера: пропустить, положить в спам или выкинуть.
Вот так выглядит ответ, при котором подделка проходит:
$ dig +short TXT _dmarc.example.ru "v=DMARC1; p=none; rua=mailto:dmarc@example.ru"
p=none означает «ничего не делай, просто пришли мне отчёт». Его ставят, пока настраивают почту, чтобы случайно не порезать свои же рассылки. А потом про него забывают. В итоге письмо от мошенника с адресом director@example.ru спокойно доходит до получателя, и ни Яндекс, ни Gmail его ничем не помечают.
Из 284 доменов записи удалось прочитать у 275. Получилось так:
DMARC |
Доменов |
Что будет с подделкой |
|---|---|---|
записи нет |
22 |
дойдёт во «Входящие» |
|
44 |
дойдёт во «Входящие» |
|
108 |
попадёт в спам |
|
101 |
будет отклонена |
То есть у 66 доменов (24%) подделка проходит без вопросов. Ещё у 125 частично: письмо уйдёт в спам (где его кто‑нибудь всё равно откроет), либо основной домен закрыт, а поддомены нет. Последнее, кстати, встретилось у 42 доменов: у них в записи стоит sp=none, и письмо от example.ru отклонят, а от noreply@mail.example.ru пропустят. Нормально защищено меньше трети.

Хуже всего с этим у вузов, 26 из 28. Представьте письмо «от деканата» с «новым расписанием» в начале сентября. Банки и медиа выглядят получше, но и у них проблема примерно у каждого второго.
Свой банк можно проверить прямо сейчас, это секунд десять. В Windows:
nslookup -type=TXT _dmarc.имя-банка.ru
В Linux и macOS: dig +short TXT _dmarc.имя-банка.ru. Смотрите на p=. Если там reject, всё хорошо. quarantine терпимо. А если none или ответа нет вообще, письмо от имени этого банка может прислать кто угодно, и смотреть на адрес отправителя бессмысленно.
jQuery 2013 года и готовые эксплойты

Страницы удалось прочитать у 170 сайтов (остальные встречают робота заглушкой «подтвердите, что вы не робот»). У 24% из них подключены старые версии JavaScript‑библиотек с известными уязвимостями. Чемпион, конечно, jQuery: версии 1.10, 1.11, 1.12 и 2.2, то есть 2013–2016 годы.
Почему это не мелочь. У каждой такой уязвимости есть публичное описание, а часто и готовый пример атаки. Искать дыру не нужно, она уже описана в базе CVE. Насколько опасно на конкретном сайте, зависит от того, как библиотеку используют, поэтому утилита пишет «возможно уязвимы», а не «взломан». Но если библиотеку не трогали десять лет, за сайтом, скорее всего, вообще никто не следит.
Забавный момент: на 11 сайтах утилита нашла в коде ключи Google API. Выглядит как утечка, но это не она. Такие ключи по задумке лежат в открытом виде и ограничиваются настройками на стороне Google. Утилита так и пишет и в проблемы их не записывает. Мне было важно, чтобы она не пугала там, где пугаться нечего.
Поддомены в никуда
Эта находка мне понравилась больше всего, хотя случаев немного.
Типичная история: компания когда‑то подняла блог на blog.example.ru в облаке. Проект закрыли, сервер удалили, а запись в DNS никто не убрал. Поддомен теперь смотрит на облачный адрес, который никому не принадлежит. Если кто‑то займёт этот адрес или создаст в облаке проект с тем же именем, его страница откроется по адресу компании. Со всеми вытекающими для фишинга.
Нашлось пять таких поддоменов. Четыре смотрят на пустые адреса в AWS и DigitalOcean. Пятый ведёт в облачное хранилище, которое отвечает, что такого проекта у него нет, и принадлежит он финансовой компании. Сам я, разумеется, ничего занимать не пробовал, утилита только смотрит снаружи и пишет «возможен захват, проверьте вручную».
Перехват по дороге
Тут всё скучно, но массово.
У 57% сайтов нет HSTS. Это заголовок, который говорит браузеру «ко мне только по HTTPS». Без него первый заход по старой ссылке http:// уходит открытым, и в публичном Wi‑Fi его можно подменить.
31% серверов до сих пор соглашаются на TLS 1.0 и 1.1, которые стандарт запретил ещё в 2021 году. Браузеры по ним уже не ходят, но сам факт значит, что конфиг не трогали очень давно.
У 12 сайтов сертификат кончается в ближайшие две недели. Может, автопродление сработает в последний день. А может, однажды утром сайт откроется с красным экраном.
И политика безопасности контента (CSP), которая мешает чужому скрипту утащить данные из формы оплаты, нормально настроена у двух сайтов из 184. Двух.
Ваш IP уходит раньше, чем вы что‑то нажали
Если открыть главную среднего сайта из выборки, ваш браузер тут же отдаёт IP‑адрес, а часто и cookies, пяти сторонним сервисам. У 19 сайтов таких сервисов десять и больше, у рекордсмена 27. Большинство российские: Метрика, VK, рекламные сети. Но у 51% сайтов среди них есть иностранные, и чаще всего это Google Analytics.
С 1 марта 2023 года о трансграничной передаче персональных данных нужно уведомлять Роскомнадзор заранее. IP и cookies, которые ушли в Google, это она самая.
Самое интересное началось, когда я научил утилиту сравнивать политику конфиденциальности с тем, что на сайте реально происходит. Расхождение нашлось у 31% сайтов. Пара цитат (без названий):
«Компания не осуществляет трансграничную передачу данных, обрабатываемых с использованием Сайта, Мобильного приложения, Мессенджеров»
На этом сайте стоит Google Analytics.
«Данные не передаются третьим лицам»
А на странице Meta Pixel, рекламная сеть и ещё несколько счётчиков.
Я не думаю, что кто‑то врёт нарочно. Политику пишет юрист по шаблону, счётчики ставит маркетолог, и между собой они, похоже, не разговаривают. Но объяснять это Роскомнадзору будет неприятно.
Один рубильник на всех
Тема прошлой статьи тоже никуда не делась. Серверы за границей остались всего у четырёх сайтов из 284, тут крупный бизнес молодец. Но иностранный сертификат у 74% (GlobalSign у 126, Let's Encrypt у 72), почта в Google Workspace у 20, DNS в Cloudflare у 13. Если кто‑то из этих провайдеров завтра решит отключить российских клиентов, у компании разом встанет почта или сайт.
С блокировками отдельная ирония. Шесть сайтов подключают у себя домены из реестра блокировок, в основном виджеты Facebook, и у посетителей без VPN эти куски страницы просто не грузятся. А у восьми сайтов IP оказался в реестре из‑за соседа по хостингу или CDN.
Ещё на 13 сайтах есть ссылки на Instagram и Facebook без пометки, что Meta признана в России экстремистской организацией. Практика по таким ссылкам пока мутная, поэтому утилита пишет «внимание», а не «нарушение».
Госсайты
Честно, я ждал, что тут будет строже всего. Не угадал. Из 18 доменов почту можно подделать (полностью или частично) у 10. Из 14 сайтов, где удалось прочитать заголовки, нормальной CSP нет ни у одного, защитных заголовков не хватает у восьми, HSTS у половины. Три сервера ещё принимают TLS 1.0. Справедливости ради, с иностранными сервисами у госсайтов полный порядок: Google Analytics нашёлся только у одного.
Что с этим делать
Почти всё чинится за вечер.
С почтой главное не ставить сразу p=reject, иначе можно отрезать собственные рассылки. Нормальный путь такой: сначала p=none с отчётами, неделю смотрите, кто отправляет письма от вашего имени, добавляете эти сервисы в SPF, потом переходите на p=quarantine и в конце на p=reject. И не забудьте про поддомены:
_dmarc.example.ru. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.ru"
HSTS и старый TLS в nginx закрываются двумя строчками:
ssl_protocols TLSv1.2 TLSv1.3; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Поддомены стоит раз в полгода пролистать и удалить всё, что ведёт на закрытые проекты. Список поддоменов, которые видит весь интернет, лежит в журналах сертификатов на crt.sh. jQuery и прочее из времён первой версии сайта пора обновить. А с Google Analytics решение простое: либо уведомить Роскомнадзор и написать о передаче в политике, либо убрать счётчик. Его часто ставили давно и благополучно забыли.
Почему этой утилите можно доверять
Понимаю скепсис: очередной сканер от одного человека. Поэтому пару слов о том, как он устроен.
Каждая проверка сделана по стандарту, а не по ощущениям. Почта по RFC 7208 (SPF), 7489 (DMARC) и 8461 (MTA‑STS), TLS по RFC 8996, заголовки по OWASP Secure Headers, 152-ФЗ по тексту закона и КоАП. И у каждого вывода в отчёте лежит доказательство: DNS‑запись, заголовок ответа, адрес скрипта, цитата из политики. Всё можно перепроверить руками, если не верите.

У проверок постоянные ID, как в нормальных сканерах (SUV-MAIL-003 это всегда DMARC), чтобы находку можно было отслеживать и сравнивать между прогонами. Тестов больше тысячи, и ни один не ходит в сеть. Есть ещё полигон из 158 синтетических сайтов с заранее известным правильным ответом: если какая‑то проверка начинает отвечать иначе, сборка падает. А каждую ночь утилита сама прогоняет те же 297 реальных сайтов и разбирает, что изменилось: сайты или её собственный код.
Отчёт выдаётся в HTML, PDF и Word, есть сводка на одну страницу для руководителя, SARIF для GitHub, GitLab и DefectDojo, коды выхода для CI. Можно воткнуть проверку в конвейер и не выпускать релиз, если на сайте появилась новая дыра.
Сама утилита тоже не дырявая. Сайты она открывает в браузере с песочницей и без доступа к вашей локальной сети. Код открыт под AGPL. Exe собирается в GitHub Actions, подписан через Sigstore, к нему лежат SBOM и контрольные суммы, и проверить, что он собран именно из этого кода, можно командой gh attestation verify.
Чего пока нет, так это замера точности на реальных сайтах по ручной разметке. На полигоне утилита отвечает правильно во всех случаях, но полигон я придумал сам. Как часто она ошибается в жизни, покажут ваши комментарии.
Где я сам наступил на грабли
Пара историй из этого исследования, потому что гладко ничего не прошло.
Первая сводка, которую выдала моя же утилита, сообщила, что фишинг от имени компании возможен у 100% сайтов. Для заголовка было бы бомбически, но это неправда. Доля считалась только среди сайтов, где сценарий нашёлся, а не среди всех. Так что все цифры в статье я пересчитал вручную из сырых отчётов.
Дальше прогон упал на первой же минуте. Сайты проверялись по четыре одновременно, и всем четырём сразу понадобился реестр блокировок. Они бросились скачивать его в один и тот же временный файл, и Windows не дал второму процессу его тронуть. На Linux я бы этого, скорее всего, вообще не заметил. Теперь файл качается один раз, а остальные ждут.
Ещё одна история: проверка компаний по перечню Росфинмониторинга на fedsfm.ru у меня всегда отвечала «не удалось установить защищённое соединение». Я долго думал, что сайт лежит. А у него просто сертификат Минцифры, которому не доверяет ни Windows, ни Python, да ещё и без промежуточного сертификата. Пришлось положить сертификаты Минцифры в утилиту и доверять им только для этого одного сайта, а не для всего интернета.
И спасибо комментаторам прошлой статьи. Мне подсказали базу IP2Location, и это было в точку: страну сервиса утилита определяла по владельцу сети, а для 152-ФЗ важно, где сервер стоит физически. Теперь она смотрит ещё и открытую базу DB‑IP.
Ограничения
Проверялись главная и несколько внутренних страниц, без браузера, так что всё, что дорисовывает JavaScript, могло пройти мимо. Страницы прочитаны у 170 сайтов из 284, и всё про 152-ФЗ, скрипты и библиотеки посчитано только по ним; «не проверено» я нигде не смешивал ни с «хорошо», ни с «плохо». Часть прогона шла через зарубежный канал. Почту, DNS и сертификаты это не трогает, а вот страницы части банков и госсайтов из‑за границы не открываются. Ну и 152-ФЗ утилита проверяет по признакам на страницах, юриста она не заменяет.
Попробовать
Код открыт: https://github.com/marsilid/suveren
Для Windows в Releases лежит готовый Suveren.exe, двойной клик открывает меню. На других системах:
pip install "suveren[browser]" suveren scan example.ru --browser
Отчёт покажет по вашему сайту всё то же самое: можно ли подделать почту, какие библиотеки устарели, нет ли брошенных поддоменов, куда уходят данные посетителей и что чинить первым.
Если утилита на вашем сайте ошиблась, напишите в комментариях. Одна из новых проверок появилась как раз из комментария к прошлой статье.
Комментарии (151)

RTFM13
08.11.2026 22:18IP и cookies, которые ушли в Google, это она самая.
"Сомнительно, но окэй." (с)
Но уж пользователю об этом переживать надо в самую последнюю очередь.

marsilid Автор
08.11.2026 22:18Да, тут я резковато сформулировал. Однозначной практики нет, РКН считает что может быть ПДн, суды по-разному. И да, это больше риск для владельца сайта, чем для пользователя

pae174
08.11.2026 22:18Тема DKIM не раскрыта.

marsilid Автор
08.11.2026 22:18Справедливо, в статью не влезло. По цифрам: ключи нашлись у 190 доменов, и у 157 из них (83%) есть ключ на 1024 бита, хотя RFC 8301 советует от 2048. Письма с ними пока принимают, но запас уже небольшой. Ну и селекторы DKIM снаружи не перечислить, утилита пробует типовые имена, так что что-то могла не найти

BillGilbertN
08.11.2026 22:18@marsilid полезная утилита! Но есть нюанс - после проверки одного сайта утилита выводит в консольное окно, где работает (windows) отчёт. Затем предлагает нажать Enter для возврата в меню. Нажатие - прокрутка окна наверх. Если после этого выбрать пункт 1, ввести сайт - новые данные проверки будут писаться прямо поверх старой информации и получается каша. Добавьте cls)
PS если саму утилиту положить в Downloads\reports (который она сама создала после первого отчёта) и запустить еще раз - она создаст Downloads\reports\reports еще раз и так далее. Контролируйте создаваемые папки.

marsilid Автор
08.11.2026 22:18Спасибо, оба подтверждаю. Экран на Windows чистится не до конца, отсюда каша, а папка reports создаётся рядом с exe, даже если он уже внутри неё лежит. Поправлю в следующей версии

LiliJulie
08.11.2026 22:18Чтоб терминал не глючил при перезаписи строк лучше выводить промежуточный статус через стандартный curses или rich, тогда буфер очищается предсказуемо на любой операционке. И пути к репортам надо сразу лочить через Pathlib относительно рабочего каталога

marsilid Автор
08.11.2026 22:18Спасибо, так и сделано: статус через rich, пути через pathlib от рабочей папки. Если где-то увидите кривой вывод, пришлите скрин и название терминала, поправлю.

Weron2
08.11.2026 22:18Любая программа создает папку рядом со своим экзешником, если так задумано. Вы хотите чтобы отчет в папке документы создавался? По мне удобнее когда рядом с exe

marsilid Автор
08.11.2026 22:18Так и сделано, при двойном клике отчёты пишутся в папку reports рядом с exe, из консоли туда, откуда запустили.

GDragon
08.11.2026 22:18Рассуждать в одной статье об опасности МИТМ и одновременно что у сайтов "Но иностранный сертификат" - довольно странно как по мне.
Если что, иностранные сертификаты не запрещены законодательством РФ.
LuciusWill
08.11.2026 22:18не запрещены законодательством РФ
С учётом, куда движется политика правительства, это лишь вопрос времени.

salnicoff
08.11.2026 22:18А Вы позвоните в колл-центр Сбербанка (в настоящий, разумеется). Просто ради интереса. Вам там будут гнать такую же пургу: иностранные сертификаты — это плохо, потому что они иностранные, и только минцифровские нельзя взломать.

marsilid Автор
08.11.2026 22:18Не, я не про то что минцифровские надёжнее. Как раз наоборот, им браузеры не доверяют

BillGilbertN
08.11.2026 22:18Вы считаете, что Минцифры виновато в том, что потребовалось создавать УЦ и выпускать сертификаты? А может быть из-за того, что однажды кое-кто взял и отозвал кое у кого CA-шки? Без объявления войны, регистраций и СМС...

marsilid Автор
08.11.2026 22:18Я никого не виню, отчёт просто показывает два разных риска. Сертификат зарубежного центра не запрещён, и Suveren не считает его нарушением. Это зависимость, как и любой иностранный сервис: в 2022 году некоторые центры правда отзывали сертификаты и переставали их выпускать для части российских компаний. Сертификат Минцифры этот риск снимает, но у него свой: браузеры, кроме Яндекс Браузера и Атома, ему не доверяют, и обычный посетитель увидит ошибку. Поэтому многие ставят оба сертификата. Какой риск важнее, каждый решает сам, моя задача только показать оба.

Farinkey
08.11.2026 22:18они могли создать внушающий доверие УЦ, который соответствует стандартам безопасности и прозрачности. но почему-то решили что их эти требования не касаются

BugM
08.11.2026 22:18Примерно как eMudhra? Всем стандартам соответствует, все сертификации и аудиты прошел. Отличный УЦ.

inkelyad
08.11.2026 22:18УЦ сделал глупость и его больше нет(сам закрылся под влиянием тех самых мер, которые против ошибок УЦ применяются). А клиенты благополучно у других УЦ подписываются.
Но теперь представим себя на месте индийских организаций, которые обязаны вот таким государственным пользоваться. Зная, что они вот такие раздолбаи.
Или на месте российских, если кто-нибудь вдруг обнаружит что-то похожее про сертификаты Минцифры. Вопрос, кстати, что при этом произойдет - будет вообще кто-то озабочиваться добавлением его вот во все эти черные списки (как нам напомнили, отзыв - далеко не единственный способ воздействия), или нет.Тут, кстати, нужно еще раз подумать, полезно или вредно, что кто-то другой решает, кому можно доверять или нет. Не было бы всех этих инструментов воздействия третьими лицами - вообще непонятно, как ситуация бы развивалась. Здоровенная часть клиенты eMudhra, поди, так бы то сих пор ничего и не сделали, оставаясь сидеть на скомпрометированной цепочке.

BugM
08.11.2026 22:18Конечно будут. Никому не нужно чтобы делали митм на банки. Все заблочат и перевыпустят.

Jesus05
08.11.2026 22:18Никому кроме своих-же спецслужб...

MountainGoat
08.11.2026 22:18А спецслужбам зачем mitm на банки, у них и так доступ ко всему банку есть?

RTFM13
08.11.2026 22:18например, чтобы выдать свои действия за чужие и списать всё на хакеров из какой-нибудь недружественной страны.
есть например неединичные случаи где клиенты банков отрицают передачу кодов из смс посторонним (то что его можно угадать с огромной по криптографическим меркам вероятностью пока вынесем за скобки). кто на самом деле передал код? как это проверить?

Fisher324
08.11.2026 22:18А где у минцифры факапы сравнимые с eMudrha?

inkelyad
08.11.2026 22:18А где у минцифры факапы сравнимые с eMudrha?
Как тут правильно указали, у eMudrha тоже не было. До определенного момента. И потом построенная система сработала более-менее как задумано. В частности - все разбежались от них к другим.
А вот как это все сработает с УЦ Минцифры - вот совсем не очевидно. В частности, разбежаться на другие УЦ уже не получится же?

RTFM13
08.11.2026 22:18Вообще сильно не хватает интерфейса расстановки галочек на странах к которым принадлежат УЦ. Каждый чекнул бы "своих" и успокоился.
Я бы форкнул этот чекер и индию (и еще кучу кого) захардкодил бы в блоклист. Остальных раскрасил бы по степени доверия.

BugM
08.11.2026 22:18Американцы такого не допустят. Контроль им важнее риска рассыпания интернета на части. Все должны доверять их сертификатам и только им.

inkelyad
08.11.2026 22:18Да ладно. Способы вставить частные УЦ для корпоративных нужд у всех браузеров и ОС есть. И Минцифровский УЦ пока никто в блеклисты не заносит, хотя он уже порядочно много где стоит. Если будут заносить - наверное. покажут, почему.
Так что "Все должны доверял только им" - это несколько преувеличено.Система, действительно, порядком кривая, но совсем не по причине целенаправленного желания, а просто потому что забывают думать о том, что в других местностях могут хотеть.

BugM
08.11.2026 22:18Речь про дефолты, хотя бы в Хроме и Винде. Вон у нас уже полгода пытаются добавить сертификат в доверенные и до сир пор проникновение далеко от 100 процентов.
Миром правят умолчания.

RTFM13
08.11.2026 22:18Так им и так доверяют. При чем практически все. Американцы потому, что несанкционированная слежка за своими гражданами там не поощряется. А люди в "недружественных" странах потому, что они не сливают данные кому попало.

BugM
08.11.2026 22:18Ну ок. Ждём первого МИТМ на Сбер или Госуслуги. До этого вероятно разделегирование домена на американских ДНС серверах будет.

inkelyad
08.11.2026 22:18Кто такой серт сейчас подпишет-то? Как раз после eMudhra поставщики браузеров дерганные и злые. Закатают такой УЦ в черный список и не сильно поморщатся.

BugM
08.11.2026 22:18Да кто угодно. Кто не захочет УЦ лишиться. Ну точнее не лишиться, а быть выкинутым из доверенных в Хроме Винде и далее по списку.

inkelyad
08.11.2026 22:18Что-то мне кажется, что сейчас подиписать MitM серт (а это почти наверняка заметят) - гораздо более надежный способ быть выкинутым из доверенных, чем отказаться. Как раз по описанной причине.

BugM
08.11.2026 22:18Все ровно наоборот. Разделегируют домен, санкции же. Выдают его кому надо. Выпускают сертификат. Все легально.
За отказ выпустить сертификат выкидывают из доверенных за нарушение правил работы.

inkelyad
08.11.2026 22:18Так это уже не система сертификатов злономеренно используется, а доменная. Да и то - непонятно, как оно будет работать, пока DNSSec ключи зоны ru - под нашим контролем. Снести всю .ru - это, пожалуй, можно. А вот отельный домен из нее - этот самый DNSSec хоть на уроне пользователей не очень виден, но самими корневыми серверами зон еще как проверяется.

BugM
08.11.2026 22:18Американские корневые сервера что надо примут. Не переживайте.
Какая злонамеренность? Санкции введут и все будет по их закону. Еще и куча народа в комментариях тут поддержит.
Раньше минусовали карму даже за утверждение что система сертификатов будет использована американцами как оружие. Сбылось. Сейчас за предположение что американцы будут делать митм. И ведь велик шанс что тоже сбудется. Году этак в 28-29, если демы победят.

selivanov_pavel
08.11.2026 22:18Это же политический вопрос. После 22 года ни одна компания, опасающаяся американских или европейских санкций, не поставит российский УЦ в список доверенных, чему бы он там не соответствовал.

salnicoff
08.11.2026 22:18Так и я о том же. Всех заставили выучить мантру о безопасности серта минцифровского, а какая дыра за ним стоит, сотрудники колл-центра не понимают. Да еще и борзеют: не нравится — вали.

marsilid Автор
08.11.2026 22:18Согласен, это разные риски и я их в статье зря рядом поставил. Иностранный сертификат никак не про MITM и не запрещён, с безопасностью у GlobalSign и Let’s Encrypt всё нормально. Риск там другой: что УЦ откажет в продлении, как было в 2022. Поэтому и написал что зависимость вынужденная, без НУЦ браузеры сайт не откроют

GDragon
08.11.2026 22:18Да, это я понимаю :)
p.s.
Проблема именно в том что МИТМ, это скорее про отечественный...

nApoBo3
08.11.2026 22:18Читаешь текст и вроде как все по делу, но все равно с душком. Слон то в комнате есть.

LuciusWill
08.11.2026 22:18Это всё даже агенты легко могут проверять и исправлять. Буквально, пара запросов к агенту. Но всё равно, у нас такая ужтсная ситуация. В общем, как всегда, миром правит лень и безалаберность.

miksoft
08.11.2026 22:18"Миром правит не тайная ложа, а явная лажа" :)

silicon_stone
08.11.2026 22:18строго говоря, Пелевин забыл указать ещё один вариант: "Тайная ложа, совершающая явную лажу". И таких в истории немного есть ))

inbuckswetrust
08.11.2026 22:18Миром правит тот кто спонсирует РЕН ТВ ну и остальные "пусть говорят" :) к гадалке не ходи, ну или пытаются править.

RTFM13
08.11.2026 22:18Не помню откуда, возможно оттуда же - если кто-то некомпетентный занимает своё место, значит это кому-то выгодно. Опять же, если кждый раз в результате "лажи" деньги перемещаются в одном и том же направлении, то можно не сомневаться.
DVORYAN
Я бы даже не стал добавлять в заголовок «Рунета». Описанные вами проблемы характерны для всех отраслей и сфер.
Я пользуюсь одной библиотекой видов, которую регулярно обновляют: на сайте есть жизнь, крупнейшая база видов, информация по генетике и так далее. И вот всё, что вы описали, там присутствует. Сервер можно буквально пинком открыть, даже парсер никто не блокирует. Заходи кто хочешь, бери что хочешь.
Просто ресурс настолько нишевый, что он никому особо не интересен.
marsilid Автор
Да, согласен, это вообще не только у нас. Просто я гонял именно российские сайты, плюс тут ещё 152-ФЗ сверху, поэтому и Рунет в заголовке.
А нишевые сайты как раз самые интересные) Никто не смотрит, а потом на таком сервере внезапно майнер или фишинг висит. Киньте ссылку на ту библиотеку, если не жалко, прогоню через утилиту, интересно что вылезет
LuciusWill
Зачем ограничиваться лишь сайтами рунета? Было бы ещё интереснее оценить состяние глобального интернета.
marsilid Автор
Утилита под Россию заточена, там 152-ФЗ и реестр блокировок. Но почту и TLS можно проверять у кого угодно.
inbuckswetrust
Интересно когда вы "гоняли" вы сами никакую статью не нарушили ?
softi
а в чем нарушение, если это не используется для получения какой-либо выгоды?
marsilid Автор
Тут дело не в выгоде, по 272 УК она не нужна. Важно, лезешь ли ты туда, куда тебя не пускали. Suveren в закрытое не лезет: открывает публичные страницы, как обычный браузер, и читает открытые DNS-записи и реестры. Портов не сканирует, пароли не подбирает, уязвимости не проверяет.
marsilid Автор
Старался не нарушить. Suveren по умолчанию делает то же, что обычный посетитель: открывает главную и несколько страниц, читает публичные записи DNS и открытые реестры. Портов не сканирует, пароли не подбирает, уязвимости не проверяет. Всё, что выходит за это, включается только для своего сайта после подтверждения владения. Поэтому и названия сайтов в статье не привожу.
Mike-M
До чего же метко сказано! Вот подтверждение на примере федеральной сети аптек: https://otzovik.com/review_18715521.html
xenon
Если какой-то непонятный нишевый сервер можно взломать - то могут залить криптолокер и требовать биткоины за ключ для расшифровки. Если данные на сайте ценны и интересны хотя бы его владельцам (а правильную полноценную бэкап-процедуру заменяют три иконки) - то это вполне себе ценный и интересный ресурс для всех, кому интересны деньги.