mercredi 1 juillet 2009

Le syndrome HTTP


Avez-vous été prévenu de la naissance d'un nouveau réseau ? Le fameux réseau « port 80 » et son copain, le réseau « port 443 » ? On réinvente les couches réseaux au-dessus d'HTTP qui n'est plus vu comme un protocole à rapprocher des couches hautes du modèle OSI mais comme un nouveau protocole de transport universel. Pourquoi diable en sommes nous arrivés là ? Et est-ce vraiment une si bonne idée ?

HTTP c'est bien parce que c'est pur porc 80 (euh pardon... port 80 !) ! Eh oui ça passe les pare-feux en standard donc il vaut mieux utiliser HTTP comme transport et s'encapsuler dedans... C'est la porte ouverte à toutes les fenêtres ! C'est sûrement pour cela qu'on a inventé les ports TCP et les pare-feux...

En gros, comme paramétrer un pare-feu c'est compliqué1, on préfère n'autoriser qu'un nombre réduits de ports. Mais on ne réduit pas pour autant le nombre de protocoles, puisque ces derniers vont se cacher dans HTTP. Alors bien sur y'a la solution logique de complexifier encore plus les pare-feux en les rendant plus intelligents et capables de reconnaître les protocoles caché dans HTTP plutôt que de se fier au numéro de port. Bref, pourquoi faire simple ?

Revenons aux sources du mal : la (pseudo) sécurité. En effet, si HTTP est devenu le « passage » par défaut, c'est parce qu'il permet très souvent de « passer les pare-feux ». Mais ces derniers ne sont ils pas justement là pour « bloquer » les communications illégitimes ? Et pourquoi diantre utiliser HTTP pour contourner ces pare-feux ? Simplement parce qu'une autre aberration sécuritaire énonce que plus on ferme de ports possible, plus on est en sécurité, bien à l'abri des méchants hacker. N'importe quoi !

Avec des outil à la portée de tous on peut aujourd'hui aisément construire des tunnels SSH au travers d'une connexion HTTP (le seul pré-requis - pas cher – est de disposer d'un serveur SSH qui écoute sur le port 443) et, hop, on sort du réseau. De plus en plus de personnes ont d'ailleurs recours à ce genre de mécanismes pour répondre à des besoins légitimes comme récupérer les sources d'un projet libre encore géré par CVS (ou même parfois Subversion) car une mauvaise configuration de proxy (intentionnelle ou pas) peut rendre impossible la récupération via HTTP de code source.

Bref, un technicien un minimum débrouillard contourne en moins de 5 minutes la politique de sécurité... Alors quid du hacker ? Il rît, et il passe...

Pendant ce temps, les utilisateurs standards ne cessent de souffrir car leurs clients de messagerie ne peuvent se connecter en POP ou IMAP, ou parce que la bande passante - surchargée par l'usage de HTTP pour tout et surtout n'importe quoi - n'est pas suffisante. Finalement, en lieu et en place d'une architecture réseau claire, où chaque flux circule dans son propre tuyau, permettant ainsi du faire du contrôle sur le contenu et la légitimité du trafic ; on obtient un réseau où tout, absolument tout, passe dans HTTP, y compris, caché discrètement dans ce foutoir où l'on ne peut rien contrôler, notre pirate, hilare.

Du coup comme HTTP est vu comme le protocole de transport mondial, on reconstruit toutes les couches réseau au-dessus d'un protocole qui n'a pas initialement été conçu pour cela. En effet, HTTP est un protocole déconnecté, sans état. Il a été fabriqué comme cela pour permettre aux serveurs et ne pas avoir à retenir des informations entre les différentes requêtes d'un même client et ainsi pouvoir traiter un grand nombre de clients.

HTTP a pris la grosse tête avec le succès du Web et se prend désormais pour IP ! Que se passe-t'il pour la grenouille qui veut se rendre aussi grosse que le bœuf ? Elle éclate. C'est joli, mais pas très efficace.

Et puis les différents types de caches positionnés dans les architectures pour optimiser les performances mettent le souk dans tout ça, qu'il s'agisse de proxy ou de reverse-proxy. Alors, pour calmer le jeu, on utilise l'instruction CONNECT de HTTP, celle servant normalement à faire passer les flux cryptés, pour ouvrir un socket vers la destination, en traversant tous les intermédiaires, proxy, pare-feux, etc.

Pourquoi ne pas aller jusqu'au bout de cette logique et de créer des VPN sur HTTP ? Ben oui ! OpenVPN par exemple le permet. C'est pratique, on refait passer un flux IP encapsulé dans HTTP lui même encapsulé dans IP. Vu comme ça cela paraît aberrant, non ? Mais au moins cela permet d'éviter d'avoir à recréer une nouvelle stack réseau au-dessus d'HTTP et de réutiliser celle d'Internet. A quand une API OpenVPN dans les serveurs d'applications et les navigateurs ? Comme les poupées gigognes, on peut alors, juste pour rire, ouvrir un autre VPN sur une couche HTTP de ce nouveau réseau. « C'est pas grave, les machines sont de plus en plus rapides. »

Et ce qui est sympa avec HTTP, c'est qu'on est pas certain que les flux ne seront pas manipulés au passage. Il faut donc travailler en mode texte, le plus basique possible. Et voilà qu'entrent en jeu XML, les encodage b64 ou hexa, etc. Beaucoup de bruit, de traitements, de trafic réseau... pour rien !

On se retrouve obligés de réinventer pas mal de roues pour permettre des appels distantsde procédures ou de services. La catastrophe a commencée avec l'apparition des services Web et des protocoles SOAP et WSDL. Cela partait d'un bon sentiment pourtant : créer une couche d'interopérabilité pour pouvoir rendre les applications Web agnostiques en termes de technologies. Mais c'est aussi un moyen de repousser le problème et de masquer l'incapacité du monde informatique à gérer l'interopérabilité (mais je réserve ce sujet à un autre coup de gueule).

Donc un fois la planche bien savonnée, il ne restait plus qu'à se lâcher avec la pléthore de surcouches ou de compléments : WS-Security, WS-Transaction, WS-Coordination, WS-Addressing, WS-Transfer (celui là a un nom prometteur...), WS-Notification, WS-Policy, WS-Reliability, WS-ReliableMessaging, WS-Resource, WS-Federation, WS-CAF (Composite Application Framework), WS-CDL (Choreography Description Language), WS-Discovery, WS-Eventing, WS-Federation, WS-MetadataExchange, WS-Trust, WS-Topics, ... STOP !!! Arrêtons le massacre ! On savait pas faire tout ça avant l'apparition d'HTTP et des services Web ? Avec des protocoles conçus pour cela et éprouvés par l'usage ?

Même pour une simple connexion vers une queue de messages, il faut encapsuler plusieurs sockets dans un seul. En effet, un service de messages doit pouvoir en recevoir mais également en envoyer. Comme il est interdit, par le pare-feu, au serveur de messages de contacter directement le client, ce dernier utilise un protocole simulant deux connexions dans une seule qu'il a initié. Pour faire passer dans HTTP, on ajoute un nouvelle couche.

Même les jeux en lignes utilisent cela. Par exemple, le célèbre jeu Dofus utilise une pseudo connexion HTTP via une requête CONNECT pour communiquer avec le serveur. En réalité, le flux est en clair. Les pare-feux ne se rendent même pas compte que la connexion SSL a été abusée. A quoi servent-il ?

En outre, on a perdu toutes les couches protocolaires de type broadcast. Pour diffuser un flux radio, il faut désormais une connexion par auditeur. Impossible d'envoyer un flux à un groupe d'auditeurs. Idem avec la vidéo. La catastrophe est annoncée, avec la généralisation de la diffusion vidéo en HD. Si toutes les vidéos de YouTube étaient en HD, le réseau ne tiendrait pas. Crac.

Parce qu'y'en a marre de la médiocrité, des RSSI qui interdisent tout systématiquement sans réfléchir et de la disparition des petits administrateurs système soucieux du travail bien fait et conscients de leurs responsabilités.

Jean-Pierre Troll jp.troll@gmail.com
(parce que là au moins je peux consulter ma messagerie à travers n'importe quel pare-feu !)