Команда разработчиков curl выпустила обновление для устранения уязвимости CVE-2025-5025, оцененной как средней (Medium Severity).
Уязвимость проявляется при выполнении трех условий:
1. Используется TLS-библиотека wolfSSL 2. Соединение устанавливается по протоколу HTTP/3 (QUIC). 3. Включена функция безопасности certificate pinning (пиннинг публичного ключа сертификата сервера).
Проверка пиннинга не выполнялась. Это означает, что злоумышленник может провести атаку 'Атака посредника' (MITM-атака) и представить любой действительный сертификат, curl примет соединение, несмотря на несоответствие ожидаемого ключа. Это позволяет злоумышленнику перехватывать и модифицировать зашифрованный трафик.
Опубликована 83-я версия кэширующего и антиспамного прокси-сервера для персонального использования c гибкими настройками.
Основные функции (всё настраивается):
фильтрация нежелательного контента (белые/чёрные списки на урлы, запрет кук);
принудительное и бессрочное кеширование полученных данных (в основном удобно для картинок и скриптов);
исправление содержимого веб-страниц на лету (правкой исходника на Си, есть пример для замены содержания страниц-клонов stackoverflow ссылкой на оригинал);
чёрные/белые списки сертификатов и certificate pinning по списку;
подмена айпи-адреса/домена/пути/протокола http-запроса по конфигу (такой расширенный вариант /etc/hosts);
http/https-сниффер.
Прекрасно подходит для просмотра сайтов через медленный интернет или с медленного устройства (благодаря п.1 и 2, ради которых изначально всё и затевалось), но вообще полезно в любом случае.
Прокси-сервер в целях безопасности и упрощения логики работы разделён на три части: TLS-сервер (терминирующий браузерные подключения), центральный модуль прокси и клиент, терминирующий исходящие подключения.
Программа рассчитана на персонализированное использование, то есть все конфиги и директория с текущими данными прокси-сервера привязана к конкретному пользователю, или даже к конкретному профилю браузера. Запустить прокси в качестве общесистемного демона технически возможно, но в таком виде затруднительно использовать одну из его главных функций - агрессивное кеширование всего подряд, поскольку закешированные данные у каждого профиля браузера могут быть свои, и должны быть изолированы друг от друга в целях безопасности.
https://my.local.site
set proxy none
set target http://127.0.0.1:1234/localsite
set http_host new.host:1234
.intel.com
resolve off
set proxy socks5://127.0.0.1:3333
В случае обновления с версии более старой чем 78 следует сконвертировать кеш: зайти в рабочую директорию прокси-сервера от юзера (uid/gid) прокси-сервера и выполнить fproxy-cacheconv-78 (по умолчанию эта программа не компилируется).
fproxy-dashboard теперь имеет опцию для показа размеров контента в байтах а не кбайтах;
поддержка багнутых серверов, игнорирующих заголовок «Connection: close»;
поддержка багнутых серверов, отдающих некорректный заголовок «Content-Encoding: identity»;
отправка TLS-опции ALPN;
улучшение работы TLS-терминатора внешней стороны (клиента): он теперь поддерживает не только TLS, но и обычные соединения,
поддерживает работу в виде независимого демона с приёмом запросов от основного прокси по сети, а также может пробрасывать свои
исходящие соединения через другое прокси, таким образом позволяя гибко разделять задачи между узлами в условиях плохого
интернет-соединения и/или необходимости организовать «выход» трафика где-то на удалённом сервере разной степени доверенности;
так же новая версия более удобна для использования вручную из командной строки в качестве консольного TLS-клиента с поддержкой
проксирования;
упрощена сборка, теперь есть Makefile вместо шелл-скриптов
организованы предсобранные .deb-пакеты в репозитории (для версий Debian 8-12)
изменения файла конфигурации, обратно-несовместимые
новый конфиг для управления роутингом запросов, объединивший ранее бывшие отдельными конфиги resolv и включения проброса
исходящих соединений на удалённый сервер, а так же получивший ряд новых опций: теперь можно для каждого url-а (протокол,
домен, порт, путь) выбирать через какой клиент, какое прокси он будет отправлен, через чей днс-сервер будет проводиться
определение его айпи-адреса (включая опциональное делегирование этой задачи внешнему прокси-серверу http или socks5), либо
прописать адрес вручную, а так же заменить протокол, порт или префикс пути url-а
добавлена поддержка SAN-сертификатов для ip-адресов и в клиенте и в сервере (браузеры с некоторых пор перестали принимать
ip-адреса в CommonName)
В планах на будущее:
поддержка CGI/FastCGI/.so хуков для mitm-обработки полученного от сайтов контента
менеджер профилей и конфигураций прокси
интерактивное управление проверкой сертификатов удалёных сайтов и списками блокировок
Срок действия сертификата SSL, используемого ПАО Сбербанк для защиты своих сервисов, истёк сегодня. Поскольку все корневые сертификаты контролируются США, а также из-за политики санкций, удостоверяющие центры, имеющие право выпустить новый сертификат, отказали ПАО Сбербанк в продлении.
Поэтому с сегодняшнего дня ПАО использует новый сертификат выданный от имени «Russian Trusted Sub CA». Загрузить его можно с сайта госуслуг. По указанной ссылке доступны файлы сертификата и инструкции для популярных ОС (Linux в списке отсутствует). Сайт госуслуг удостоверяется сертификатом, выданным Sectigo и поэтому пока доступен в любых браузерах.
Также новый сертификат уже встроен в браузеры Яндекс.браузер и Атом.
Завершилось голосование по поправке SC27v3 к Базовым Требованиям, согласно которым удостоверяющие центры выдают SSL-сертификаты. В итоге поправка, разрешающая при определенных условиях выписывать DV- или OV-сертификаты на доменные имена .onion для скрытых сервисов Tor, принята.
Ранее допускалась только выдача EV-сертификатов из-за недостаточной криптографической стойкости алгоритмов, связанных с доменными именами скрытых сервисов. После вступления поправки в силу, станет допустимым метод валидации, когда владелец скрытого сервиса, доступного по протоколу HTTP, делает на сайте запрошенное удостоверяющим центром изменение, например, размещение файла с заданным содержимым по заданному адресу.
В качестве альтернативного метода, доступного только для скрытых сервисов, использующих onion-адреса версии 3, также предлагается допустить подпись запроса на сертификат тем же ключом, который используется скрытым сервисом для Tor-маршрутизации. Для защиты от злоупотреблений в этом запросе на сертификат необходимо наличие двух специальных записей, содержащих случайные числа, сгенерированные удостоверяющим центром и владельцем сервиса.
За поправку проголосовали 9 из 15 представителей удостоверяющих центров и 4 из 4 представителей компаний, разрабатывающих веб-браузеры. Голосов против не было.
Сегодня обсуждается уже полная «блокировка» сертификатов от подконтрольных Symantec центров: в Chrome ориентировочно с выпуска 66 (запланирован на 17 апреля 2018) предлагается отвергать сертификаты выпущенные ранее 1 июня 2016 и с 70 — полностью все; в Firefox несколько ранее — с декабря 2017 года, также поэтапно с полным отказом ориентировочно в выпусках 63 (16 октября 2018) или 64 (27 ноября 2018).
Под санкции попадают также CA GeoTrust, Thawte и RapidSSL, которые связаны с проблемными центрами цепочкой доверия.
Разработчики Google Chrome рассматривают меры снижения доверия и постепенную блокировку сертификатов (через снижение срока их действия), выданных подконтрольными Symantec центрами сертификации. Недовольство и опасения вызвала политика выдачи сертификатов, которые компания проводила предыдущие несколько лет. Symantec недостаточно тщательно контролировала процесс выдачи сертификатов, что привело к снижению безопасности пользователей Google Chrome.
Такие «мягкие» меры объясняются тем, что подконтрольные Symantec центры занимают значительную долю: по разным данным 30-40% всех проверок касаются сертификатов выданных проблемными CA.
Предлагаемые меры:
EV-сертификаты предлагается рассматривать как DV сроком на год. Если не будет предпринято мер по исправлению ситуации со стороны CA, политика снижения доверия продолжит действовать.
В Chrome 59 значение максимального срока действия сертификатов Symantec планируется ограничить 33 месяцами, Chrome 60 — 27 месяцами, Chrome 61 — 21, и в итоге в Chrome 64 — 9 месяцами. Кроме того, для всех новых сертификатов предлагается сразу ограничить срок действия 9 месяцами.
За это время CA подконтрольным Symantec (Symantec, Thawte, GeoTrust) предлагается заменить все «малодоверенные» сертификаты и устранить недостатки в процессах их выдачи.
Команда OpenSSL, популярного и широко используемого криптографического ПО, как ранее и заявляла, планирует сменить лицензию на Apache 2.0 и в связи с этим обращается ко всем разработчикам, которые когда-либо вносили свой вклад в развитие проекта, чтобы они одобрили это изменение. Ранее уже было принято решение требовать от сторонних разработчиков передавать права на патчи по CLA соглашению.
Лицензия Apache 2.0 совместима с GNU GPL v3, в отличие от оригинальной лицензии OpenSSL.
Как-то осталась незамеченной новость о том, что 3-го декабря проект Let’s Encrypt перейдя в состояние бета-релиза начал раздавать доверенные сертификаты всем желающим (уже без необходимости регистрации).
Спустя 3 года с выпуска прошлой версии вышел vsftpd 3.0.3.
Vsftpd отличается своей простотой настройки, высокой производительностью, а также повышенным вниманием к безопасности. Vsftpd используется как ftp-сервер по умолчанию на серверах многих известных проектов, таких как Linux, Red Hat, Debian, FreeBSD и других.
Консорциум Linux Foundation объявил о взятии под своё крыло Internet Security Research Group (ISRG) вместе с их проектом Let’s Encrypt, в рамках которого осуществляется создание первого в мире бесплатного, автоматизированного и открытого удостоверяющего центра.
Let’s Encrypt позволит владельцам сайтов получать бесплатные SSL-сертификаты в течение считанных минут. Эта процедура будет избавлена от излишней бюрократизации и полностью автоматизирована, а операции по выпуску и отзыву сертификатов полностью прозрачны и публичны.
Запуск центра сертификации планируется уже в середине этого года.
Для Google Chrome 42 cтало реальностью заявление, сделанное еще осенью 2014 года о пометке небезопасными браузером сертификатов, использующих алгоритм SHA-1.
Однако, затронуты будут не все сертификаты. Результат отображения статуса сертификата зависит от его даты выдачи.
Тихо и незаметно произошло обновление стабильной версии Firefox до 37.0.1. Выпуск является корректирующим с исправлением двух серьезных уязвимостей.
Первая является критической: ошибка позволяет обойти проверку SSL сертификата в HTTPS соединениях с использованием протокола HTTP/2, что делает возможным проведение MITM атак. Злоумышленник, манипулируя заголовком Alt-Svc, задействует HTTP/2 режим шифрования без аутентификации. Для шифрования не требуется прохождение процедуры подтверждения подлинности сервера. Уязвимость устранена отключением поддержки HTTP/2 Alt-Svc.
Вторая уязвимость позволяет обойти ограничения режима Reader Mode (режим читателя). Ошибка проявляется на Android версии и в сборках для разработчиков. Также устранены ошибки, приводящие к краху браузера в определенных условиях: при некоторых сочетаниях графического оборудования и стороннего ПО.
Исследователи из INRIA, IMDEA и Microsoft обнаружили новый тип атаки на SSL/TLS, названный FREAK (Factoring attack on RSA-EXPORT Keys). Злоумышленник может вклиниться в соединение и инициировать ослабление шифрования между клиентом и сервером, что повышает его шансы расшифровать трафик.
Около двух месяцев назад инженер Bodo Möller совместно с Thai Duong and Krzysztof Kotowicz из Google Security Team обнаружил уязвимость в SSL — POODLE (Padding Oracle On Downgraded Legacy Encryption), которая позволяет осуществлять Man-in-the-Middle (MitM) и расшифровать информацию между клиент-сервером.
Теперь (два дня назад), SSL-гуру Adam Langley из Google обнаружил новую уязвимость (CVE-2014-8730) в TLS v1.x, которая, в некоторых реализациях не проверяет дополнение /англ. «padding»/ после дешифровки в режиме CBC.
В новой версии атаку осуществить намного проще: теперь не нужно спускаться с TLS до SSLv3, а просто достаточно вставить вредоносный JavaScript. Успешная атака использует около 256 запросов чтобы дешифровать 1 байт cookie, или 4096 запросов для 16-ти байтного cookie. Это делает атаку достаточно практичной.
Хорошей новостью является факт, что только 10% серверов подвержены данной атаке (судя по докладу SSL Pulse).
Adam Langley упомянул в своём блоге: «Все протоколы до TLS 1.2 с AEAD шифром криптографически поломаны».
Разработчики браузера Firefox объявили об отказе от поддержки SSL 3.0 в следующем выпуске браузера (Firefox 34). Это связано с публикацией сведений о новом типе атаки на протокол, которая фактически сводит к нулю всю защищенность SSL 3.0. Корпорация Google также заявила о прекращении поддержки SSL 3.0 в ближайших выпусках Chromium/Chrome.
Отмечается, что в результате пострадает крайне небольшое число сайтов (0.3%), да и то, большая часть из них поддерживает этот протокол лишь в целях совместимости с IE6 (в котором есть поддержка TLS, но отключенная по умолчанию).
В настоящий момент атаке подвержены все защищенные соединения с сайтами, поддерживающими SSL 3.0, поскольку, даже при использовании протокола TLS, злоумышленник может заставить обе стороны переключиться на менее защищенный протокол, вызвав сбой при установке TLS-соединения.
В процессе аудита кода GnuTLS (свободной реализации протоколов TLS и SSL, предоставляющей приложениям API для обеспечения надежной связи по протоколам транспортного уровня) сотрудниками RedHat была обнаружена критическая уязвимость CVE-2014-0092.
Данная уязвимость схожа с недавно опубликованной уязвимостью в iOS и MacOS, когда из-за одной строчки кода проверка подлинности сертификатов фактически не выполнялась. Уязвимость находится в коде, отвечающем за проверку подлинности сертификатов X.509, и позволяет обойти эту проверку на всех выпусках GnuTLS с помощью специальным образом созданного сертификата. Например, злоумышленник может организовать атаку типа Man-in-the-Middle, а затем использовать поддельный сертификат для перехвата зашифрованного трафика жертвы. Некоторые эксперты по безопасности не исключают даже возможности распространения фальшивых обновлений пакетов в дистрибутивах Linux, поскольку невозможно с уверенностью сказать, не была ли их цифровая подпись подделана.
В одном только Debian библиотеки GnuTLS используются более, чем 350 пакетами. Уязвимости подвержены даже такие библиотеки, как libcrypt, libmailutils и cURL, которые тоже завязаны на GnuTLS, и используются для обновления других пакетов и работы почтовых приложений. Проблема усугубляется тем, что по лицензионным соображениям Debian и Ubuntu используют GnuTLS вместо OpenSSL, поэтом проблема затрагивает уже установленные Nginx, Apache и приложения VPN.
