IETF объявила о депрекации TLS 1.0 и TLS 1.1

IETF объявила о депрекации TLS 1.0 и TLS 1.1

IETF объявила о депрекации TLS 1.0 и TLS 1.1

Рабочая группа по развитию интернет-технологий (Internet Engineering Task Force, IETF) обновила рекомендации по использованию криптопротокола TLS, официально списав версии 1.0 и 1.1 как устаревшие.

Спецификации TLS 1.0 были опубликованы в январе 1999 года, через семь лет IETF их обновила, утвердив TLS 1.1. С тех пор требования к надежности передачи данных возросли; появились новые, более криптостойкие механизмы и шифры, поддержки которых в этих версиях протокола нет.

Уязвимость реализаций TLS 1.0/1.1, связанную с использованием устаревших алгоритмов (MD5, SHA-1), неоднократно доказывали исследователи — в частности, авторы атак ROBOT, DROWN, POODLE, BEAST, Logjam и FREAK.

С 2008 года в наиболее критичных областях хозяйственной деятельности рекомендуется использовать TLS версии 1.2, но и этот стандарт уже обновлен — три года назад был одобрен TLS 1.3, способный обеспечить еще большую безопасность.

Новый документ RFC 8996 окончательно упраздняет TLS 1.0 и 1.1, объявляя их не соответствующими современным требованиям. В приложениях, предназначенных для использования в госсекторе и промышленности, поддержку этих протоколов рекомендуется снять. Согласно IETF, такая мера позволит уменьшить площадь атаки, сократить число ошибок конфигурации и упростить сопровождение библиотек и программных продуктов.

В разряд устаревших также переведен протокол DTLS 1.0; вместо него рекомендуется использовать DTLS 1.2 (версия 1.1 не выходила).

По данным веб-сервиса SSL Pulse компании Qualys, в начале февраля TLS 1.2 использовали 99,3% сайтов из 150 тыс. наиболее посещаемых по версии Alexa. Поддержка версии 1.3 была включена на 42,9% сайтов. Тем не менее, больше половины популярных сайтов допускали откат до TLS 1.1, а 48,7% — до TLS 1.0.

В настоящее время поддержка TLS 1.0/1.1 в основных браузерах отключена; ее также постепенно удаляют из других приложений и сервисов.

Telegram MCP-сервер fast-mcp-telegram пустил атакующих к телеграм-сессии

В fast-mcp-telegram нашли критическую уязвимость под идентификатором CVE-2026-52830: хотели защититься токенами bearer, а в итоге превратили токен в путь к файлу. В результате атакующий может получить доступ к MCP-сессии Telegram по HTTP без валидного закрытого токена.

Fast-mcp-telegram — это MCP-сервер, который подключает телеграм-аккаунты к ИИ-ассистентам и HTTP-клиентам через сессионную модель аутентификации.

В версиях до 0.19.0 включительно проверка токена устроена так: сервер берёт строку из Authorization: Bearer, добавляет к ней .session, склеивает с директорией сессий и проверяет, существует ли такой файл.

Проблема в том, что токен не нормализуется как безопасный идентификатор. Код запрещает некоторые зарезервированные имена, например telegram, но не блокирует слеши, «..», абсолютные пути и другие конструкции.

Вместо закрытого ключа сервер фактически принимает относительный путь в файловой системе. Отличный подарок для атакующего, плохая новость для владельца телеграм-аккаунта.

В типичной конфигурации дефолтная сессия лежит в файле ~/.config/fast-mcp-telegram/telegram.session. Прямой токен telegram отклоняется, но обходной вариант вроде ../fast-mcp-telegram/telegram может схлопнуться файловой системой в тот же самый файл. Если файл существует, сервер принимает такой токен и аутентифицирует атакующего как дефолтный телеграм-аккаунт.

После этого злоумышленник может читать и отправлять сообщения, вызывать MTProto API и использовать доступные инструменты, привязанные к этой сессии. Защита на уровне префиксов инструментов тут уже не спасает: она срабатывает после аутентификации, а дверь к аккаунту к тому моменту уже открыта.

Уязвимость затрагивает fast-mcp-telegram до версии 0.19.0 включительно. В версии 0.19.1 разработчики ужесточили проверку и начали обращаться с bearer-токенами как с непрозрачными идентификаторами, а не как с кусками пути.

Администраторам рекомендуют срочно обновиться, ротировать дефолтные и старые session-файлы, а также проверить логи на подозрительные bearer-значения со слешами и «…».

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