Каждое зашифрованное соединение, которое вы устанавливаете сегодня — будь то через TLS или QUIC — начинается с единого согласования безопасности. Ключи, согласованные в этом начальном рукопожатии, защищают весь сеанс. Если злоумышленник перехватит трафик и позже получит ключ, всё содержимое этого сеанса станет доступно для чтения задним числом. Это известный структурный пробел в модели транспортной безопасности интернета, который инженерное сообщество принимало десятилетиями. Предложение рабочей группы IETF, продвинутое на встрече в Вене на этой неделе, может это изменить.
Во вторник вечером на IETF 126 сессия Birds-of-a-Feather под названием CURRENT — Continuous Updating and Ratcheting for Rekeying Encrypted Network Transport — провела своё первое официальное собрание и выступила за создание новой рабочей группы IETF. Цель: применить механизмы управления ключами Messaging Layer Security (MLS) к общему сетевому транспорту, обеспечив долгоживущие зашифрованные сеансы непрерывным обновлением ключей, которое уже защищает текстовые сообщения на iOS и Android. Это было подтверждено в официальном списке сессий BoF IETF.
IETF 126 проходит с 18 по 24 июля в Вене. Сессия CURRENT стала первой формальной проверкой того, считает ли инженерное сообщество проблему реальной, область её решения — поддающейся, и достаточно ли инженеров готовы выполнить эту работу.
Что на самом деле означает непрерывное обновление ключей (ratcheting)
TLS 1.3 и QUIC оба обеспечивают прямую секретность — но лишь в ограниченном смысле. Они согласовывают ключи сеанса во время рукопожатия, и новый сеанс означает новые ключи, поэтому прошлые сеансы остаются защищёнными, даже если будущий ключ украден. Чего они не обеспечивают — так это защиты после компрометации в рамках текущего сеанса, пробел, задокументированный в стандарте архитектуры MLS (RFC 9750).
Защита после компрометации отличается от прямой секретности, и это различие важно. Прямая секретность означает, что прошлые сеансы защищены от будущего кражи ключей. Защита после компрометации означает, что скомпрометированная конечная точка — сервер, который был временно взломан, устройство, которое временно контролировалось злоумышленником — после очистки начнёт генерировать ключи, которые злоумышленник не сможет предсказать. Сеанс самовосстанавливается. TLS и QUIC не делают этого в рамках сеанса; MLS делает, как определено в RFC 9750.
Последствия этого пробела наиболее велики для долгоживущих соединений: корпоративные сеансы API, туннели VPN, устройства IoT, поддерживающие постоянный канал связи, спутниковые каналы с прерывистым соединением. Эти соединения удерживают ключи сеанса в течение длительного времени без повторного рукопожатия, и ключ, полученный злоумышленником в этом окне, продолжает компрометировать трафик ещё долго после момента взлома.
Предложение CURRENT заключается в использовании управления ключами MLS — в частности, его асинхронных обновлений ключей, криптографического ratchet и формально проверенных свойств безопасности — как основы для нового двухстороннего протокола на транспортном уровне, как указано в списке сессий BoF IETF 126. Двухсторонний фокус намеренно узок. MLS был создан для групп от двух до тысяч участников, но CURRENT нацелен на наиболее распространённый сценарий использования транспорта: один клиент, один сервер, постоянный зашифрованный канал между ними.
Безопасность транспортного уровня приобретает свойства прикладного уровня
Архитектурное значение CURRENT выходит за рамки конкретных свойств, которые он добавит. С момента первой стандартизации TLS в 1990-х годах существовала структурная граница между безопасностью прикладного и транспортного уровня: приложения для обмена сообщениями могли быть спроектированы с непрерывным обновлением ключей (Signal, iMessage, а теперь и RCS делают это), в то время как транспортные протоколы работали с принципиально иной моделью — одно согласование в начале, затем удержание этого состояния ключа на время сеанса.
CURRENT, если будет одобрен и в конечном итоге стандартизирован, станет первой формальной попыткой IETF внедрить свойства безопасности прикладного уровня — прямую секретность и защиту после компрометации вместе — на транспортный уровень. Ограничение двухсторонним сценарием как раз и делает это возможным: консенсус групповых ключей среди тысяч участников вносит сложность, которой избегает двухсторонний протокол.
Уже проверено на сотнях миллионов устройств
Ключевой элемент аргументации CURRENT заключается в том, что его криптографическая основа не является экспериментальной. MLS был опубликован как RFC 9420 в июле 2023 года после многих лет разработки, формального анализа безопасности и широкого общественного обсуждения внутри IETF. Он прошёл верификацию с использованием инструментов формального анализа — уровень проверки, которого не получает большинство предложений протоколов — что даёт CURRENT более надёжную основу безопасности, чем может заявить большинство новых работ IETF.
В марте 2025 года Ассоциация GSM объявила, что RCS Universal Profile 3.0 будет использовать MLS в качестве стандарта сквозного шифрования, как подтверждает объявление IETF о принятии MLS в RCS. К маю 2026 года Google Messages и Apple Messages начали активное внедрение MLS E2EE для пользователей, сделав RCS первой крупномасштабной службой обмена сообщениями, поддерживающей совместимое сквозное шифрование между разными поставщиками платформ, согласно записи в Wikipedia о Messaging Layer Security, касающейся внедрения RCS. MLS также был развёрнут внутри корпоративных платформ реального времени, включая Webex, Wire и Discord для голосовой, видеосвязи и групповых чатов — что даёт протоколу опыт промышленной эксплуатации в значительно различающихся средах развёртывания, как документирует объявление IETF о принятии MLS.
Доступные сегодня реализации MLS охватывают пять языков — Rust (OpenMLS, mls-rs), C++ (MLS++), TypeScript (MLS-TS) и другие — от организаций, включая AWS Labs, Cisco и Matrix Foundation, согласно таблице реализаций Messaging Layer Security в Wikipedia.
Как создаётся рабочая группа IETF?
Для читателей, не знакомых с процессом IETF: сессия Birds-of-a-Feather — это формальный первый шаг на пути от идеи к опубликованному RFC. BoF по формированию рабочих групп, такие как CURRENT, предназначены для ответа на три вопроса — согласно ли сообщество, что проблема реальна, достаточно ли узка область, чтобы быть решаемой, и достаточно ли инженеров готовы выполнять работу в течение лет, необходимых для завершения стандарта?
Если на эти вопросы получены положительные ответы, следующим шагом является формальный устав, одобренный Руководящей группой по интернет-инжинирингу IETF (IESG), за которым следует формирование рабочей группы и начало разработки фактических спецификаций протокола. IETF не голосует; она работает на основе общего консенсуса, оцениваемого председателями сессий и IESG.
IETF 127, запланированный на 14–20 ноября 2026 года в Сан-Франциско в Hilton Union Square, станет следующей важной вехой для CURRENT, если венская сессия пройдёт благоприятно. Записи сессий и заметки с IETF 126 публикуются в IETF Datatracker и на канале IETF YouTube по мере завершения венской встречи.
Почему постквантовая угроза делает это срочным сейчас
Есть вторая причина, по которой сообщество безопасности обеспокоено долгоживущими ключами сеанса, помимо обычного сценария компрометации: атаки «собери сейчас, расшифруй позже». Задокументировано, что государственные злоумышленники собирают сегодня зашифрованный трафик и хранят его для будущей расшифровки, как только станут доступны квантовые компьютеры, способные взломать классический обмен ключами.
Множество национальных агентств кибербезопасности — включая NSA, CISA и NIST — подтвердили, что такой сбор активно ведётся. Оценки исследований 2025–2026 годов пересмотрели требования к кубитам для взлома RSA-2048 в сторону понижения — с 20 миллионов до менее 1 миллиона, сжимая временные рамки, которые когда-то казались комфортными.
Долгоживущие зашифрованные сеансы — тот самый сценарий использования, на который нацелен CURRENT — подвергаются повышенному риску в рамках этой модели угроз, поскольку они удерживают материал ключа сеанса в течение длительного времени. Злоумышленник, который сегодня перехватит долгоживущий корпоративный сеанс API, получит большее окно контента, расшифровываемого задним числом, чем злоумышленник, перехвативший короткий веб-запрос.
Поскольку MLS уже изначально поддерживает постквантовые наборы шифров через спецификацию draft-ietf-mls-pq-ciphersuites, протокол, производный от CURRENT, не потребует отдельной постквантовой модернизации. Путь обновления встроен в основу.
Что изменится, если CURRENT добьётся успеха
Практические последствия успешного стандарта CURRENT будут наиболее значительными в развёртываниях, где соединения сохраняются: корпоративные среды, поддерживающие долгоживущие сеансы TLS с внутренними сервисами, развёртывания IoT, где устройства удерживают постоянные каналы в течение дней или недель, туннели VPN, остающиеся открытыми на время рабочего сеанса, и везде, где постоянные соединения заменяют повторные рукопожатия по соображениям производительности или задержки.
Для разработчиков и архитекторов в этих средах операционная разница будет следующей: сегодня ключ сеанса, скомпрометированный в середине длинного соединения, продолжает раскрывать весь последующий трафик в этом сеансе. В протоколе на основе CURRENT непрерывный ratchet гарантирует, что ключи быстро устаревают, и злоумышленник, владеющий одним производным ключом, не сможет предсказать следующий.
Работа, если будет одобрена, вероятно, займёт годы. Рабочие группы IETF создают интернет-черновики, которые циркулируют для рецензирования, комментариев и доработки в течение нескольких раундов, прежде чем готовая спецификация достигнет очереди редактора RFC. Путь от венского BoF до развёрнутого RFC долог. Но сочетание факторов, которые приносит CURRENT — формально проверенный базовый протокол, доказанное крупномасштабное развёртывание в RCS, встроенная постквантовая поддержка и намеренно ограниченный двухсторонний охват — даёт предложению необычайно прочную основу для новой работы по стандартизации.
Чего именно не хватает в TLS и QUIC, что добавит CURRENT?
TLS 1.3 и QUIC обеспечивают прямую секретность, согласовывая новые ключи сеанса для каждого соединения, поэтому прошлые сеансы остаются защищёнными, если будущий ключ украден. Чего они не обеспечивают — так это защиты после компрометации в рамках сеанса: если злоумышленник получает доступ к материалу ключа сеанса конечной точки в середине длинного соединения, он может продолжать читать трафик до закрытия сеанса или нового рукопожатия. Механизм обновления ключей MLS непрерывно выводит новые ключи из старых, отбрасывая старый материал, так что скомпрометированный ключ быстро становится бесполезным. CURRENT предлагает стандартизировать двухсторонний протокол, который привносит это непрерывное обновление в сетевые транспортные соединения.
Почему использовать именно MLS, а не создавать новый протокол ratchet с нуля?
MLS обладает двумя свойствами, которые делают его естественной основой. Во-первых, он был формально верифицирован с использованием инструментов математического доказательства — уровень гарантии безопасности, которого не получает большинство предложений протоколов и который новые пользовательские разработки должны были бы устанавливать с нуля. Во-вторых, он уже развёрнут в масштабе: Google Messages и Apple Messages внедрили сквозное шифрование MLS через RCS в мае 2026 года, а Webex, Wire и Discord используют его в промышленной эксплуатации. Использование уже стандартизированной и развёрнутой основы даёт CURRENT как аргумент для убедительности при создании рабочей группы IETF, так и массив реального опыта реализации, на который можно опереться.
Влияет ли это предложение на устройства и соединения, которые я использую сегодня?
Нет, немедленно. CURRENT находится на самой ранней фазе стандартизации IETF — сообщество должно сначала согласиться создать рабочую группу, прежде чем начнётся разработка протокола, а путь от устава до развёрнутого RFC обычно занимает несколько лет. Для потребительского веб-сёрфинга, который использует короткоживущие сеансы TLS, это предложение в значительной степени неактуально. Преимущество в безопасности применяется конкретно к долгоживущим соединениям: корпоративным серверным сеансам, соединениям устройств IoT, туннелям VPN и любым постоянным зашифрованным каналам, которые поддерживают одни и те же ключи сеанса в течение часов, дней или дольше.
Что означает «собери сейчас, расшифруй позже» для долгоживущих сеансов?
Задокументировано, что государственные злоумышленники и другие хорошо обеспеченные ресурсами атакующие собирают сегодня зашифрованный интернет-трафик и хранят его для будущей расшифровки, как только станут доступны квантовые компьютеры, способные взломать текущие алгоритмы обмена ключами. Долгоживущие сеансы — сценарий использования, на который нацелен CURRENT — подвергаются непропорционально большому риску, поскольку они производят большие объёмы шифротекста под одним и тем же материалом ключа сеанса в течение длительного времени. Встроенная поддержка постквантовых наборов шифров в MLS означает, что транспортный протокол, производный от CURRENT, решит эту проблему без необходимости отдельной постквантовой миграции позже.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Kyle Belmonte
