Résumé

  • FEP transportait un datagramme IP complet dans le corps HTTP ; un hôte complice à l’intérieur le décodait puis le réinjectait dans sa pile réseau.
  • Le passage de la session HTTP ne prouvait pas que la politique avait approuvé les adresses, ports, application, utilisateur ou action du paquet intérieur.

La règle reconnaissait l’enveloppe

RFC 3093 part d’une tension historique. L’architecture de bout en bout favorisait l’innovation aux extrémités ; le pare-feu d’entreprise introduisait un décideur intermédiaire. Une application nouvelle pouvait échouer non par défaut technique, mais parce que son trafic n’appartenait pas aux classes autorisées.

La réponse du document poussait la logique jusqu’à l’absurde. Puisque HTTP franchissait souvent le pare-feu, n’importe quel paquet pouvait prendre cette apparence. FEP recevait le datagramme extérieur, l’encodait en message HTTP, l’envoyait vers un logiciel intérieur, puis recréait un datagramme dans la pile protégée. Le texte promettait un résultat équivalent à l’absence du pare-feu.

Le contrôle observé restait pourtant extérieur. Le pare-feu pouvait établir que la connexion empruntait le chemin Web. Le contenu gardait d’autres adresses, ports et intentions. L’autorisation du transporteur n’était pas celle de la cargaison.

L’hôte intérieur devenait le point décisif

Le mémo affirmait respecter le modèle de sécurité parce qu’un hôte interne devait coopérer. Il supposait que le pare-feu arrêtait les menaces externes, non internes. Il faut conserver cette phrase comme prémisse du document, pas comme garantie. Le processus qui décode puis injecte du trafic arbitraire détient justement une nouvelle autorité.

L’administrateur du pare-feu contrôlait la session extérieure. L’opérateur de l’hôte décidait si FEP fonctionnait et pouvait écrire dans la pile IP. L’utilisateur choisissait l’application. Le logiciel contrôlait la reconstruction. Aucun de ces actes ne prouvait à lui seul une autorisation commune de l’organisation.

Un journal « HTTP accepté » ne décrivait donc pas le flux caché. La réception par le tunnel ne prouvait pas la réinjection. Celle-ci ne prouvait ni l’ouverture d’une socket, ni le traitement par l’application, ni un effet extérieur.

Des copies lisibles ne faisaient pas autorité

Le datagramme complet se trouvait dans le corps HTTP. FEP recopiait aussi les champs TCP et, facultativement, IP dans des en-têtes lisibles : ports décimaux, capitales pour l’urgence, durée de vie racontée en mots, adresses rendues comme noms de domaine.

RFC 3093 précise que ces copies ne servaient qu’à la lisibilité puisque le datagramme existait déjà. Une chaîne lisible ressemblant à TCP_Dport ne garantissait donc ni la destination réelle ni l’intégrité. Les deux représentations pouvaient diverger ; seul un parseur assorti d’une règle explicite pouvait déterminer la source utilisée pour reconstruire.

Le choix de requêtes GET ou de réponses GET dans les deux sens poursuivait le même objectif d’apparence. Il ne s’agissait pas nécessairement d’obtenir une ressource Web. HTTP formait une surface reconnue par l’intermédiaire. Plus ce dernier jugeait la syntaxe plutôt que l’intention, plus la satire devenait un diagnostic de politique.

Une provocation n’était pas une preuve de déploiement

La date, les encodages fantaisistes et la section affirmant qu’il n’existe pas de véritable considération de sécurité situent l’ouvrage : un document Informational provocateur, non un guide sûr. Il n’est pas nécessaire d’attribuer une intention non prouvée à ses auteurs. Le mécanisme suffit à montrer qu’une règle grossière peut devenir un transport général si une extrémité accepte d’encapsuler.

RFC 2775 étudiait la perte de transparence ; RFC 2979 les propriétés attendues des pare-feu ; RFC 2663 et RFC 3027 les difficultés des NAT ; RFC 3234 nommera ensuite les middleboxes. SOCKS5 négociait explicitement avec un relais et proposait des méthodes d’authentification. Ces textes éclairent les couches sans démontrer une implémentation de FEP.

La leçon demeure étroite : le succès d’un protocole extérieur ne remplace pas la preuve du contrôle intérieur. Il faut identifier l’extrémité du tunnel, vérifier son identité, limiter les paquets admis, enregistrer la réinjection et observer séparément l’application. Une lumière verte sur HTTP ne peut porter toutes ces conclusions.

Sources

  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