Кратко

  • Двенадцатибитный счётчик согласованности RFC 3078 позволял заметить потерю или нарушение порядка пакетов MPPE. Он не восстанавливал отсутствующий шифротекст и не доказывал доставку данных приложению.
  • Режим без состояния мог продвинуть ключ на величину разрыва. Режим с состоянием требовал отбрасывать пакеты, послать CCP Reset-Request и дождаться FLUSHED, прежде чем снова доверять таблицам шифра.

Пакет, раскрывший разрыв, сам не годился

Получатель ожидал одно значение, а увидел другое. Заголовок доказал, что локальная история неполна. Однако отправитель мог уже пройти границу смены ключа, которую получатель не наблюдал. Новое число не приносило с собой правильного состояния RC4.

В режиме с состоянием RFC 3078 требовал отбросить такой пакет, отправить CCP Reset-Request без данных и молча отбрасывать последующие пакеты до появления FLUSHED. Получив запрос, отправитель заново инициализировал таблицы RC4 и помечал следующий пакет. Отдельный Reset-Ack был не нужен: квитанцией становилось изменённое поведение потока.

Так протокол разделял диагноз, восстановление общей криптографической точки и результат приложения. Скачок подтверждал разрыв. FLUSHED позволял продолжить. Потерянное содержание не возвращалось.

До шифрования существовала цепочка решений

RFC 3078 вышел в марте 2001 года как Informational RFC. Он описывал Microsoft Point-to-Point Encryption для PPP и обновлял использование опции, общей с MPPC из RFC 2118. Интернет-стандартом документ не был.

MPPE согласовывался в опции 18 Compression Control Protocol. Инициатор предлагал поддерживаемые варианты, а ответчик обычно выбирал один: 128, 56 или 40 бит. Отдельный бит обозначал желание работать без состояния. Если согласование MPPE не предпринималось, по умолчанию шифрования не было. Если его начали и оно провалилось, соединение следовало завершить.

До передачи MPPE-данных PPP должен был достичь фазы Network-Layer Protocol, а CCP — состояния Opened. Успешная аутентификация не равнялась Opened. Доставка ключа не выбирала режим. Предложение 128 бит не доказывало их принятие. Политика «шифрование обязательно» не защищала первый пакет сама по себе.

Соседние документы намеренно делили обязанности. RFC 2548 переносил раздельные по направлению ключи MPPE в RADIUS. RFC 3079 описывал их вывод из материала аутентификации. RFC 1962 задавал согласование и reset CCP, RFC 1661 — фазы PPP. RFC 3078 отвечал за живое состояние зашифрованных пакетов.

Двенадцать бит хранили позицию, а не содержимое

Счётчик увеличивался с каждым пакетом и после 4095 возвращался к нулю. Получатель сравнивал наблюдение с ожиданием, выявлял разрыв или перестановку и определял, насколько нужно продвинуть ключ.

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

RFC 3078 говорил, что MPPE не требует надёжного канала, а Reliable Transmission из RFC 1663 обычно лишь добавляет лишние расходы ради синхронизации. Это не означало безвредность потерь. Криптографическая машина умела продолжить состояние; верхний протокол всё равно должен был восстановить или пережить отсутствующие данные.

Через MPPE проходил только заданный диапазон протоколов PPP. Бит зашифрованных данных тоже не был защищённым доказательством. Наблюдение пакета MPPE ещё не отвечало, какой трафик следовало защищать и был ли он расшифрован.

Режим без состояния догонял ключ

В режиме без состояния сеансовый ключ менялся при каждом изменении счётчика — обычно на каждом пакете. Отправитель менял его перед шифрованием, получатель — после чтения нового значения, но до расшифровки. На каждом зашифрованном пакете устанавливался FLUSHED.

Если последним было значение два, а следующим стало пять, получатель выполнял три смены ключа. После этого он мог попытаться расшифровать пакет пять без Reset-Request. Пакеты три и четыре от этого не появлялись.

«Без состояния» не означало отсутствия общего состояния. Сторонам по-прежнему требовались один начальный ключ, один алгоритм изменения, общая семантика счётчика и согласованный режим. Просто каждый пакет давал границу для локального восстановления текущей точки.

Режим с состоянием включал обратный путь в расшифровку

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

Reset-Request делал обратный путь частью восстановления прямого потока. Односторонний монитор мог увидеть разрыв и последующий FLUSHED, но не доказать запрос конкретного получателя. Сам запрос не доказывал ответ или первый корректный открытый текст. Нужны обе стороны и результат расшифровки.

RFC также предупреждал: повторная инициализация с состоянием могла привести к применению одного ключа для двух пакетов. Поэтому такой режим не следовало использовать в средах с потерями, например в туннелях второго уровня через Интернет. Это предупреждение о механизме, а не статистика развёртывания.

Согласование не имело защиты целостности

Активный атакующий мог изменить Supported Bits и повлиять на видимую силу. Локальная конфигурация могла отказаться от неприемлемого выбора и уменьшить ущерб, но не превращала обмен в аутентифицированный.

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

Историческое использование RC4 нельзя превращать в современную рекомендацию. RFC 4345 позже описал улучшенные режимы Arcfour для SSH — другой конструкции. Он напоминает, что длина ключа не исчерпывает безопасность, но не доказывает миграцию или нынешнее распространение MPPE.

Правильная квитанция сохраняет переходы

Нужно сохранить PPP-сессию и стороны, результат аутентификации, происхождение и поколение ключа без раскрытия секрета, предложения и ответы CCP, выбранную силу и режим, момент Opened. Для каждого направления нужны ожидаемый и наблюдаемый счётчики, переход через 4095, разрывы, FLUSHED, границы 0xFF, число отброшенных пакетов, отправка и получение Reset-Request, период ожидания и первый успешный открытый текст.

Затем следует верхний протокол: его последовательность, повтор, подтверждение и эффект. Совпавшие таблицы RC4 не возвращали пропавшее сообщение.

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

Источники