Chrome станет еще безопасней

Chrome станет еще безопасней

Об этом объявили разработчики компании Google. В этом году планируется полностью отделить работу обозревателя Chrome от операционной системы, поместив его в Native Client (NaCl) – мощную технологию защиты, разработанную самой компанией.

По сути, Native Client (NaCl) представляет собой отдельную среду, в которой исполняется код, «родной» для имеющейся платформы, программы. При ее создании разработчики идеально выдержали модель «песочницы», т.е. во избежание взаимодействия Native Client непосредственно с операционной системой (ОС), весь код выполняется в отдельном, изолированном контейнере. Это позволяет модулю, использовать системные ресурсы, но в тоже время ограждает ОС от возможного случайного или злонамеренного повреждения.

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

При успешном завершении проекта, разработчики еще больше усложнят жизнь хакерам, пытающимся взломать систему безопасности обозревателя, а вот пользователи смогут не опасаться внешних атак.

А пока реализация проекта только в планах, пользователям предлагается установить очередное обновление системы безопасности. В новой версии Chrome 11.0.696.68 исправлено две уязвимости. Одна из них касается некачественного кода, ссылающегося на Chromium и WebKit, а вторая ошибка целочисленного переполнения в SVG фильтрах. Кроме этого, подключена новая версия плагина Adobe Flash Player 10.3.

Бесплатные VPN начали умирать за пару дней, IP уже ни при чём

Бесплатный VPN из Telegram бодро запускается, а через несколько дней Reels замирают, YouTube уходит в бесконечную загрузку, а Gemini встречает ошибкой 403. Современные системы фильтрации научились распознавать туннели даже без расшифровки трафика.

По версии пользователя Хабра Djin22, теперь одного нового IP-адреса может быть недостаточно.

Анализаторы изучают размеры пакетов, интервалы между ними, структуру TLS-соединения и другие косвенные признаки. Если трафик ведёт себя как прокси, маскировка под обычный HTTPS уже не всегда спасает.

Один из характерных сценариев автор называет «проблемой 16 КБ»: соединение успешно устанавливается, передаёт первые данные, а затем резко замедляется или обрывается. Для борьбы с этим используют фрагментацию пакетов, уменьшение размера TCP-сегментов и десинхронизацию DPI с помощью zapret. Идея проста: сервер должен получить нормальный поток, а анализатор — головоломку.

Отдельная история — сервисы Google. Они могут учитывать TLS-отпечаток клиента и замечать, когда программа притворяется Chrome не слишком убедительно. В sing-box для более правдоподобной имитации браузера применяют uTLS.

Если Telegram не работает даже через VLESS Reality, автор предлагает ShadowTLS v3: протокол маскирует соединение под обычную TLS-сессию с разрешённым ресурсом. Ещё один приём — padding, то есть добавление случайных данных для изменения размеров пакетов и усложнения статистического анализа.

В качестве готовых вариантов Djin22 перечисляет hynet.cloud, AmneziaVPN, Red Shield VPN, Cloudflare WARP и собственные серверы на Xray или sing-box. Однако часть текста о hynet.cloud выглядит рекламно, а заявления об «эмуляции JA4», residential-маршрутизации и автоматическом переключении протоколов приводятся без независимого подтверждения.

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