Cloudflare запустила скрытый сервис Tor для своего DNS

Cloudflare запустила скрытый сервис Tor для своего DNS

Cloudflare запустила скрытый сервис Tor для своего DNS

Разработчики Cloudfare запустили скрытый сервис Tor для своего недавно анонсированного конфиденциального DNS. Он располагается по адресу dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion и доступен через tor.cloudflare-dns.com.

В начале апреля стало известно, что Cloudflare запустила собственный DNS, призванный обеспечить пользователям конфиденциальность, ускорить интернет-соединение и ограничить сбор провайдерами истории просмотров. Адрес DNS-сервера крайне прост — 1.1.1.1.

Новый сервис Cloudflare абсолютно бесплатный, воспользоваться им можно путем изменения настроек в ваших веб-браузерах или операционных системах. Сервис можно использовать на компьютерах, маршрутизаторах и смартфонах, введите в адресной строке браузера 1.1.1.1, и вы попадете на главную страницу сервиса, там можно найти инструкции.

Как работает скрытый резольвер от Cloudflare? В сущности, это скрытый сервис Tor, перенаправляющий все сообщения на соответствующие порты в 1.1.1.1, таким образом, скрывается настоящий IP-адрес пользователя.

Основное отличие использования этого сервиса от 1.1.1.1 заключается в том, что .onion-адрес представляет собой «dns4tor» плюс 49 на первый взгляд случайных букв и цифр. Эта строка длиной в 56 символов, по сути, содержит полный открытый ключ, который используется для обеспечения связи со скрытым сервисом.

«Мы просто купили tor.cloudflare-dns.com в качестве основного имени субъекта сертификата, а адрес .onion в качестве дополнительного субъекта. Таким образом, если вы зашли правильно, вы должны увидеть следующее», — пишет компания в блоге:

Разработчики также отметили высокую скорость работы резольвера.

Напомним, что на прошлой неделе была зафиксирована попытка перехвата трафика подсети 1.1.1.0/24, в которой, в частности, находится общедоступный DNS-сервер от CloudFlare. Оказалось, что трафик был перенаправлен в принадлежащую китайскому провайдеру сеть — AnchNet.

ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

Группа компаний «Солар» проверила, насколько хорошо большие языковые модели справляются с двумя самыми трудоёмкими задачами в безопасной разработке — триажем уязвимостей и их исправлением в коде. Итог исследования получился довольно показательный: популярные общедоступные модели ускоряют работу, но пока слишком часто ошибаются, чтобы полностью на них полагаться.

Эксперты Solar appScreener протестировали шесть LLM на 20 крупных приложениях на Java и Python, каждое объёмом более 100 тысяч строк кода. Для анализа использовали как облачные модели — GigaChat 3 PRO, ChatGPT 5.2 и DeepSeek 3.2, так и локальные решения on-premise, включая ChatGPT OSS, Mistral и специализированные модели DerTriage и DerCodeFix.

Сначала с помощью SAST-анализа в проектах нашли около 12 тысяч уникальных срабатываний, из которых почти 20% пришлись на уязвимости высокой критичности. После этого все модели получили одинаковый промпт с описанием уязвимости, фрагментом кода, трассой достижимости и идентификаторами CWE.

На этапе триажа результаты оказались неровными. В Java-проектах среди облачных моделей лучше всех выступил ChatGPT с точностью 60,9%, а DeepSeek показал лишь 50%. В Python-коде картина поменялась: DeepSeek добрался до 80%+, а ChatGPT показал 52,7%. Но лучший результат среди локальных решений продемонстрировала DerTriage — более 80% точности и для Java, и для Python.

С кодфиксом ситуация похожая. Для Java ChatGPT показал 61,8% точности, DeepSeek — 45,5%. В Python их показатели составили 46,6% и 44,8% соответственно. Локальная модель DerCodeFix снова оказалась впереди: 78,2% точности на Java и 83,1% на Python.

Главный вывод исследования простой: LLM действительно экономят время, но на самых ответственных этапах безопасной разработки универсальные модели пока не дают нужной надёжности. Если команда безоговорочно доверится таким инструментам, есть риск пропустить критичные уязвимости.

В «Соларе» также напоминают ещё об одной проблеме: использование облачных моделей может стать каналом утечки исходного кода. Поэтому для задач безопасной разработки компания рекомендует смотреть в сторону локальных моделей on-premise, которые работают в закрытом контуре и всё равно требуют проверки со стороны AppSec-инженера.

RSS: Новости на портале Anti-Malware.ru