Кратко

  • После успешного TLS или SASL XMPP заменял текущий XML-поток, не отправляя обычный </stream> и не закрывая лежащее под ним TCP-соединение.
  • Новый заголовок, новый ID и обновлённые функции описывали изменившееся состояние; открытый TCP, шифрование, проверка узла, успех SASL, привязка ресурса и доставка строфы оставались разными свидетельствами.

Защищённое продолжение не было продолжением прежнего рассказа

Клиент открывает XMPP-поток, сервер предлагает STARTTLS, стороны завершают TLS-рукопожатие. На уровне TCP связь та же. Но клиент не продолжает прежний XML, только теперь под шифрованием.

Он посылает новый начальный заголовок по уже защищённому соединению и не закрывает старый поток обычным тегом. Сервер отвечает новым заголовком, создаёт новый идентификатор потока и объявляет функции, действующие после TLS.

С SASL происходит похожее. Элемент <success/> фиксирует благоприятный исход проверки, но одновременно завершает полезную жизнь контекста, в котором проверка шла. Клиент начинает ещё один поток по тому же TCP; сервер выдаёт новый ID и показывает возможности для уже аутентифицированной стороны.

Протокол сберегал транспорт и отказывался сберегать смысл. Это позволяло не платить за новое TCP-соединение и не выдавать старым утверждениям незаслуженное доверие.

У сокета и XML были разные часы

RFC 6120 не употребляет «поток» как красивое название TCP. Соединение TCP двунаправленно. Отдельный XMPP-поток формально однонаправлен; диалог образуют встречные потоки сторон.

Если согласование функции требует restart, прежний поток считается заменённым. Стороны не выполняют его обычное закрытие и не завершают TCP. Они используют существующее соединение, которое могло перейти в новое состояние из-за TLS либо уровня защиты SASL. Инициатор открывает поток, получатель обязан создать свежий ID.

Поэтому restart — не переподключение. Новое TCP означало бы другую транспортную ассоциацию, возможно другой путь и новые сетевые условия. Здесь сохраняется именно нижняя ассоциация, а очищается XML-контекст.

Это также не возобновление доставки. Правило ничего не говорит о получении прежних строф, об их повторе или о состоянии удалённого приложения. Оно задаёт границу интерпретации последующих данных.

Список функций отвечал на вопрос «что теперь?»

Stream features сообщали обязательные и добровольные шаги. Пока в списке есть обязательная функция, согласование не завершено и инициатор ещё не получил общего права посылать обычные строфы. Пустой список либо только добровольные функции означали возможность перейти к нормальному обмену.

Порядок слоёв — TCP, TLS, SASL, XMPP — влиял на содержимое. Предлагаемые SASL-механизмы могут зависеть от наличия TLS. Привязка ресурса появляется для клиента только после успешной аутентификации.

После каждого restart сервер заново объявляет функции. Это не каталог возможностей продукта, а предложение для конкретной стороны в конкретной фазе. Механически унаследованный список превратил бы условную возможность в постоянное право.

Отсутствие элемента тоже не универсально. Его может быть рано показывать, он мог уже выполнить назначение или быть скрыт политикой. RFC 7590 дополнительно предупреждает: злоумышленник способен удалить STARTTLS либо отметку required. Запись сеанса доказывает увиденное на пути, но не исчерпывает свойства сервера.

TLS требовал отказаться от небезопасно узнанного

После успешного TLS RFC 6120 велит обеим сторонам отбросить сведения, полученные небезопасно над TCP до включения защиты. Среди примеров — адрес from, прежний ID потока и прежний набор функций.

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

Само шифрование всё равно не является полной аутентификацией узла. Версия и параметры TLS, предъявленная учётная опора, проверяемое имя, результат проверки и решение политики требуют отдельных записей. RFC 7590 усиливает требования: клиенты аутентифицируют серверы, серверы — клиентов, а между серверами аутентификация настоятельно предпочтительна. Зашифрованные, но не аутентифицированные соединения остаются отдельным, более слабым случаем.

Новый поток после TLS подтверждает переход протокола. Личность партнёра подтверждает процедура верификации.

SASL устанавливал результат, а не все будущие права

RFC 4422 определяет SASL как каркас сменных механизмов для протоколов с соединением. Он различает аутентификационную и авторизационную идентичности, исход обмена и возможный уровень защиты данных. Разные механизмы дают разные свойства.

XMPP переносит обмен в XML и после него требует нового потока на существующем TCP. <success/> сообщает об успехе выбранного механизма, но не завершает все условия работы клиента.

После этого обязательна привязка ресурса. Она связывает resourcepart с аутентифицированной учётной записью и потоком, отличая одновременно подключённые ресурсы. Сервер предлагает <bind/> только в потоке после SASL.

Если до привязки клиент отправляет строфу иной стороне, кроме сервера или собственной учётной записи, сервер не должен её обрабатывать и обязан завершить поток с not-authorized. TCP может быть открыт, TLS — защищать канал, SASL — завершиться успешно, но прикладная передача ещё не разрешена.

Так аутентификация не превращается во всеобщее полномочие. ID потока не становится пользователем, привязанный ресурс — долговременным токеном, а локальное принятие строфы — доказательством удалённого эффекта.

После привязки перезапуск, напротив, запрещался

RFC 6120 прямо запрещает сторонам перезапускать поток после resource binding. Отрицательное правило показывает, что restart не был автоматической реакцией на любое слово «успех».

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

Реализации нужен смысловой конечный автомат. Не начать заново после TLS — ошибка. Не начать после SASL — тоже. Начать после binding может быть такой же ошибкой. Важен не положительный результат сам по себе, а то, какие прежние факты он отменяет.

Для аудита получается цепочка, которую нельзя сжимать: TCP открыт; TLS согласован; узел проверен; SASL завершён; ресурс привязан; строфа принята локально; действие произошло удалённо. У каждого звена свой источник и предел.

RFC 6120 сделал общим то, что RFC 3920 уже выполнял

RFC 3920, опубликованный в октябре 2004 года, уже требовал новый поток после успешного TLS и после SASL-<success/>. Он задавал порядок TCP, TLS, SASL, XMPP и считал старый поток завершённым в этих точках без обычного закрывающего тега.

RFC 6120 заменил его в 2011 году и яснее сформулировал модель: заменить поток, сохранить соединение, создать новый ID, повторно объявить обновлённые функции. Историческое изменение состояло не в изобретении restart, а в превращении нескольких последовательностей в явную архитектуру этапов.

RFC 7590 в 2015 году усилил практику TLS под изменившуюся модель угроз. Корректная последовательность XMPP и достаточность криптографии, проверки сертификатов либо защиты от понижения версии по-прежнему требуют разных оценок.

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

Источники