- Les boîtes intermédiaires, telles que les pare-feu, modifient souvent la communication Internet de bout en bout.
- Il est essentiel de comprendre l’impact de ces modifications sur les normes Internet correspondantes pour identifier les risques potentiels en matière de sécurité.
- Nous recommandons que les RFC fournissent des lignes directrices claires et rigoureuses pour les clients, les serveurs et les intermédiaires afin d’atténuer ces problèmes.
Traditionnellement, les communications en réseau suivent une approche en couches, où les protocoles de la couche application, comme le protocole de transfert hypertexte (HTTP), sont censés fonctionner de bout en bout. Ces protocoles et fonctions doivent être conformes aux normes convenues (RFC) définies par l’IETF (Internet Engineering Task Force).
Dans la pratique, la communication de bout en bout est souvent interrompue par des boîtes intermédiaires, c’est-à-diredes dispositifs intermédiaireset des proxys qui améliorent la sécurité et les performances. Un pare-feu est un exemple de boîte intermédiaire, qui bloque l’accès non autorisé à un réseau interne, protégeant ainsi les utilisateurs des menaces externes. En savoir plus sur les boîtes intermédiaires.
Il est essentiel de comprendre comment ces boîtes intermédiaires et d’autres affectent les chaînes de traitement des communications et les RFC correspondantes pour identifier les risques potentiels en matière de sécurité.
Mes collègues, Mahmoud Attia et Marc Dacier, et moi-même avons récemment cherché à examiner l’impact des proxies, un type courant de middlebox (figure 1), sur la conformité HTTP/1.1 telle qu’elle est définie par les RFC correspondantes (voir l’article).
Nous avons identifié 47 règles et testé la conformité de douze proxys populaires, dont quatre réseaux de diffusion de contenu (CDN) – des composants clés de l’infrastructure qui améliorent les performances et la sécurité des sites web. Nos résultats ont révélé trois comportements distincts, à savoir certains proxys :
- Abandonnez les paquets non conformes.
- Transférer les paquets non conformes tels quels.
- Modifier les paquets non conformes en paquets conformes.
Les mandataires ont un comportement très incohérent
Nos résultats indiquent que tous les mandataires se sont comportés de la même manière dans 7 des 47 cas de test. Les mandataires ont des comportements très incohérents dans les 40 autres cas de test, ce qui révèle des ambiguïtés dans l’interprétation des RFC (figure 3).
En outre, aucun des mandataires n’a suivi une politique uniforme pour traiter les données non conformes. Par exemple, Cloudflare, l’un des principaux CDN, a modifié les paquets dans 17 cas de test, les a transmis tels quels dans 20 cas et a rejeté les paquets non conformes dans 10 cas.
En outre, les serveurs mandataires présentaient des incohérences entre le traitement des demandes des clients et les réponses des serveurs. La RFC 9112 impose de rejeter ou d’assainir les messages contenant des caractères non valides (CR, LF ou NUL). Alors que tous les serveurs mandataires ont rejeté de tels messages client-serveur, cinq serveurs mandataires ont modifié les réponses serveur-client, tandis que sept serveurs mandataires les ont transmises sans les modifier.
Les RFC peuvent être améliorés
Notre étude identifie deux problèmes importants dans les RFC HTTP/1.1 :
- Terminologie inadéquate
- Manque d’exhaustivité
Les RFC HTTP/1.1 précisent parfois des exigences claires pour les “clients” et les “serveurs”, mais laissent les “mandataires” dans l’ambiguïté.
Cela permet aux développeurs de mettre en œuvre des proxys comme ils l’entendent, mais cette flexibilité introduit également des vulnérabilités potentielles, telles que la contrebande de requêtes.
Nous recommandons que les RFC fournissent des lignes directrices claires et rigoureuses pour les clients, les serveurs et les intermédiaires afin d’atténuer ces problèmes. Les normes devraient définir explicitement la manière dont les mandataires doivent traiter les données non conformes, par exemple en rejetant par défaut les demandes mal formées.
À l’avenir, nous souhaitons étudier les règles au niveau des recommandations en plus des règles au niveau des exigences, analyser les nouvelles versions de HTTP (HTTP/2 et HTTP/3) – qui introduisent une plus grande complexité et des optimisations – et explorer plus avant l’impact des spécifications RFC et des boîtes intermédiaires sur la conformité du protocole. La résolution de ces problèmes contribuera à des implémentations HTTP plus sûres sur l’ensemble du web.
Ilies Benhabbour est un étudiant en doctorat travaillant sous la supervision du professeur Marc Dacier à KAUST. Ses recherches portent sur les problèmes liés à l’existence de boîtes intermédiaires dans les réseaux.
Les opinions exprimées par les auteurs de ce blog sont les leurs et ne reflètent pas nécessairement celles de l’Internet Society.