Кратко

  • FEP переносил полный IP-дейтаграмм в теле HTTP; сотрудничающий внутренний хост декодировал его и вводил в свой стек протоколов.
  • Успех HTTP-соединения доказывал лишь допуск внешнего носителя, а не разрешение внутренних адресов, портов, приложения, пользователя, инъекции или результата.

Правило узнавало оболочку

Документ начинался с конфликта между новшествами на краях и контролем в пути. Новое приложение могло работать на двух хостах, но не пройти корпоративный экран, потому что его протокол отсутствовал в правилах. RFC 3093 довела ответ до сатиры: если HTTP обычно проходит, любой дейтаграмм может надеть его форму.

Маршрут был подробным. Внешний хост передавал дейтаграмм FEP. Программа помещала его в HTTP-сообщение и отправляла обычным путём. Внутри другая программа извлекала байты, восстанавливала IP-дейтаграмм и помещала его в защищённый стек, как будто экрана не существовало.

Однако экран наблюдал внешнюю сессию. Внутренний пакет сохранял собственный источник, назначение, транспорт и смысл. Решение о перевозчике само по себе не переходило к грузу.

Внутренний помощник становился центром полномочий

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

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

Поэтому запись «HTTP принят» не была журналом скрытого потока. Получение туннелем не доказывало инъекцию; инъекция — принятие сокетом; сокет — обработку приложением или внешний результат.

Читаемые заголовки оставались копиями

Полный IP-дейтаграмм находился в теле HTTP. FEP также копировал поля TCP и необязательные поля IP в читаемые заголовки: десятичные порты, регистр букв для срочности, время жизни фразой и кажущийся источник доменным именем.

Сам RFC говорил, что копии нужны только для чтения, поскольку дейтаграмм уже присутствует. Видимое TCP_Dport не удостоверяло настоящее назначение. Представления могли расходиться; программе требовалось выбрать авторитетный источник, проверить значения и применить политику до инъекции.

GET-запросы и ответы в обоих направлениях тоже использовали знакомую форму. Внутренний пакет не становился обычным веб-запросом. HTTP был поверхностью, которую распознавал посредник. Узнать синтаксис и узнать намерение — разные проверки.

Провокация сохранила реальный диагноз

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

RFC 2775 обсуждала утрату прозрачности, RFC 2979 — поведение экранов, RFC 2663, 3027 и 3234 — NAT и промежуточные устройства. SOCKS5 явно договаривался со шлюзом и предусматривал методы аутентификации. Это соседний контекст, а не свидетельство работы FEP.

Вывод узок: правило может правильно разрешить HTTP и ничего не решить о внутренней семантике. Доказательство контроля требует идентифицировать и аутентифицировать туннель, ограничить внутренние пакеты, записать инъекцию и отдельно наблюдать приложение. Успех одного слоя не заменяет отсутствующие квитанции остальных.

Источники

  1. https://www.rfc-editor.org/info/rfc3093
  2. https://www.rfc-editor.org/rfc/rfc3093.html
  3. https://www.rfc-editor.org/rfc/rfc3093.txt
  4. https://datatracker.ietf.org/doc/rfc3093/
  5. https://www.rfc-editor.org/errata/rfc3093
  6. https://www.rfc-editor.org/rfc/rfc2775.html
  7. https://www.rfc-editor.org/rfc/rfc2979.html
  8. https://www.rfc-editor.org/rfc/rfc3234.html
  9. https://www.rfc-editor.org/rfc/rfc2663.html
  10. https://www.rfc-editor.org/rfc/rfc3027.html
  11. https://www.rfc-editor.org/rfc/rfc1928.html
  12. https://www.rfc-editor.org/rfc/rfc2616.html
  13. https://www.rfc-editor.org/rfc/rfc793.html
  14. https://www.rfc-editor.org/rfc/rfc791.html
  15. https://www.rfc-editor.org/rfc/rfc2119.html