Etat de l’art du protocole http2

Principes de fonctionnement du protocole http2

La validation de http2 par l’IETF a conclu près de 3 années de travail du groupe de travail httpbis. Formé en 2007, les travaux ont focalisé tout d’abord sur une évolution de http1.1, puis ceux concernant une refonte radicale du protocole HTTP ont débuté en 2012. Aujourd’hui, 6 documents référencés par les RFC 7230 à 7236, définissent le fonctionnement et les extensions du protocole http1.1. La spécification du protocole http2 [DR2] a été acceptée en Mai 2015. En réalité, pour le développement de http2, les membres du groupe de travail ne sont pas partis d’une feuille blanche, mais se sont très fortement inspirés du protocole SPDY [DR3] [DR4] développé initialement par Google. Ce protocole fut développé et implanté dans le navigateur Chrome de Google et sur un serveur open-source dès 2012. Ainsi, le protocole SPDY est utilisé depuis 2012 dans la plateforme de Google, mais aussi plus récemment par tous les autres navigateurs (Opera, Firefox (mi 2012), Safari, Internet Explorer (fin 2013)). De nombreuses avancées de SPDY sont de fait présentes dans la spécification de http2, tout en conservant une rétro compatibilité vers http1.1. En 2012 Google estimait SPDY 23% plus rapide sur les réseaux mobiles. Au 1er février 2015, http2, implanté depuis quelques mois (activé par défaut dans Firefox 34 – Décembre 2014), représenterait 5% du trafic web. Aujourd’hui, Google arrête SPDY lancé en 2009, pour une migration officielle à http2. Page 11 Le contenu de ce document est la propriété d’Airbus Defence and Space SAS. Il ne doit pas être diffusé à d’autres personnes que les destinataires. Sa reproduction non autorisée est interdite. Tous droits réservés. En près de 20 ans d’existence, HTTP (http1.0 [RFC 1945] dans sa version initiale proposée en 1996), a beaucoup évolué. Seulement trois ans après sa sortie, la version http1.1 est venue la remplacer, avec près de 176 pages de spécifications. Les usages du protocole ont aussi beaucoup évolué. Ainsi, si une page web contenait quelques objets (texte, image) et faisait moins d’une centaine de kilooctets en 1996, la taille moyenne d’une page web est aujourd’hui de 1,9 Mo, et le nombre moyen d’objets est d’une centaine. La taille moyenne d’une page web a augmenté de 150% en 3 ans. Ainsi, le protocole HTTP a dû évoluer pour s’adapter à ce nouveau contexte. Historiquement, http1.0 n’autorisait que le transfert d’éléments individuels, successifs, au travers d’une seule connexion TCP. Avec peu d’objets échangés, ce mécanisme suffisait, mais rapidement des solutions d’optimisation ont dû être trouvées. Deux techniques ont été proposées, la première consistant à paralléliser les connexions HTTP au travers de multiples connexions TCP. Ainsi, ont été autorisées entre 6 et 8 connexions TCP parallèles (depuis 2008), soit autant de connexions HTTP, pour échanger les objets. Le deuxième mécanisme, implanté dans http1.1, consiste à autoriser l’émission de plusieurs requêtes HTTP au sein d’une même connexion TCP, sans attendre la réponse des précédentes. Ce mécanisme se nomme pipelining. Ainsi, il est possible, en un seul aller-retour, de requérir de nombreux objets. Bien sûr ces mécanismes peuvent-être combinés pour plus d’efficacité. Toutefois, ce mécanisme de pipelining n’est pas sans inconvénient. En effet, des chercheurs ont conclu de possibles interactions néfastes entre le pipelining HTTP et l’algorithme de Nagle de TCP. En effet, ce dernier, pour éviter un trop fort overhead d’encapsulation TCP, bufferise les données TCP pendant un certain temps avant de transmettre le segment dans lequel elles sont regroupées, pour avoir suffisamment de données à transmettre. Le prochain segment étant transmis à la réception de l’acquittement du précédent. Ainsi, ce mécanisme de mise en tampon au niveau 4, se rapproche du multiplexage de connexion au niveau 7, et induirait une latence d’un facteur 1,5 par rapport à une version sans Nagle. Il a donc été recommandé de désactiver l’algorithme de Nagle (TCP_NODELAY) quand le pipelining est utilisé. De plus, en cas d’utilisation d’un serveur mandataire, celui-ci doit séquencer les requêtes multiplexées, ce qui est difficile quand un client adresse plusieurs serveurs. De fait, devant toutes ces difficultés, le pipelining http1.1 est désactivé par défaut dans les navigateurs commerciaux actuels. Par contre, le nombre de connexions TCP parallèles est en moyenne de 38 aujourd’hui ! En effet, afin d’accélérer les transferts, les sites web jouent sur différents nom pour un même serveur (par exemple : www1.mondomaine.fr et www2.mondomaine.fr), afin d’autoriser l’ouverture de nouvelles connexions TCP, comme ce pourrait-être le cas pour un nouveau site. Le nouveau protocole http2 introduit quelques nouveautés. La grande nouveauté est surtout l’adoption d’un format binaire pour les messages échangés. Cette évolution amène principalement une réduction de la taille des headers. En effet, http2 définit des trames pour la structuration de ses messages. La structure d’une trame suit un format précis décrit dans le standard. Une trame commence toujours par un header d’une longueur fixe de 9 octets, suivi du payload d’une longueur variable. Le header comporte les informations suivantes :  Length (24 bits) : un entier non signé pour coder la longueur du payload ;  Type (8 bits) : Type de la trame. Ce qui détermine le format et la sémantique de la trame ;  Flags (8 bits) : Un champ réservé pour positionner des indicateurs concernant la trame ;  R (1 bit) : Un bit réservé, toujours mis à 0x0 ;  Stream Identifier (31 bits) : Un entier non signé pour identifier un flux HTTP. Le flux identifié par l’entier 0x0 est associé à la connexion (identifiant réservé)

La sécurité dans http2 : couche de transport TCP-TLS 

Pourquoi TCP-TLS

 Historiquement le protocole de la couche transport TCP était le support du protocole applicatif HTTP. TCP est un protocole offrant un service de communication fiable et ordonné sous la forme d’un flux d’octet. Avec la nouvelle version de http qui prône l’utilisation d’une connexion sécurisée, c’est naturellement le couple TCP-TLS qui s’est imposé comme support de transport. 

 Principes des échanges

 Ce paragraphe rappelle les principes de fonctionnement de TLS et les messages échangés. http2 reposant sur TLS ces détails sont utiles à la compréhension des échanges. TLS repose sur un cryptage à clés asymétriques (clés publiques et privées). Le serveur, au travers de son certificat envoi sa clé publique au client (certifiée par une autorité de certification pour éviter les attaques de type man in the middle). Avec cette clé, le client va pouvoir crypter une pré-clé qu’il aura généré et l’envoyer de manière sécurisée au serveur. Avec ces informations, pour la session, le serveur et le client génèreront quatre clés qui seront utilisées pour le cryptage des échanges (ces clés ne sont pas échangées). Au terme de cet échange, le client envoi le message CLIENTFINISHED, chiffré et signé a l’aide des clés ci-dessus. Cela signifie qu’à partir de ce moment, le client communique de cette manière. Page 15 Le contenu de ce document est la propriété d’Airbus Defence and Space SAS. Il ne doit pas être diffusé à d’autres personnes que les destinataires. Sa reproduction non autorisée est interdite. Tous droits réservés. Voici comment se passe le dialogue, dans l’ordre chronologique de haut en bas. En vert sont représentés les messages optionnels (par exemple si le certificat sur serveur est déjà connu): Figure 3 – Etablissement d’une connexion TLS Voici les explications des messages envoyés : -> CLIENT HELLO Le client envoi la version maximale supportée (TLS = 3.1), de la suite d’algorithmes supportés (par ordre de préférence décroissant) et une valeur aléatoire de 32 octets. Le contenu du message est le suivant : Version – La plus haute version de SSL que puisse utiliser le client. Random – Un horodatage de 32 bits et une valeur aléatoire de 28 octets générée par le client. Le nombre obtenu va servir la signature des messages. Session ID – Un nombre, qui identifie la connexion. Un zéro signifie la volonté du client d’établir une nouvelle connexion sur une nouvelle session. Un autre nombre signifie la volonté de changer les paramètres ou de créer une nouvelle connexion sur la session existante. CipherSuite – Une liste, par ordre décroissant de préférence, des algorithmes que supporte le client. Il s’agit des algorithmes d’échange de clé et de chiffrement. Compression Method – Liste, par ordre décroissant de préférence, des algorithmes de compression supportés par le client. Puis le client attend une réponse du serveur : <- SERVER HELLO Le serveur effectue le choix de la version, de la suite d’algorithmes (Cipher Suite) et d’une valeur aléatoire. Le message contient : Version – La plus haute version de SSL que puisse utiliser le client. Page 16 Le contenu de ce document est la propriété d’Airbus Defence and Space SAS. Il ne doit pas être diffusé à d’autres personnes que les destinataires. Sa reproduction non autorisée est interdite. Tous droits réservés. Random – Un horodatage de 32 bits et une valeur aléatoire de 28 octets générée par le client. Session ID – L’Identifiant de la session qui débute. CipherSuite – La séquence d’algorithmes choisis pour la session. Le serveur sélectionne la première suite qu’il connait dans la liste transmise par le client. Compression Method – La méthode de compression qui va être utilisée. Maintenant que les algorithmes sont choisis, le serveur va s’authentifier auprès du client. Il envoie pour cela son ou ses certificats (X.509) au client. Il peut pendant cette étape demander un certificat au client. Le client vérifie l’authenticité du serveur : si cette authenticité est mise en doute, la transaction est interrompue. * CERTIFICATE (optionnel) Envoi d’une chaine de certificats par le serveur. Le premier certificat est celui du serveur, le dernier est celui de l’autorité de certification * CERTIFICATE REQUEST (optionnel) Demande un certificat au client pour l’authentifier * SERVER KEY EXCHANGE (optionnel) Message complémentaire pour l’échange des clés. Ce message contient la clé publique du serveur utilisée par le client pour chiffrer les informations de clé de session <- SERVER HELLO DONE Fin des échanges Hello du serveur. * CERTIFICATE (optionnel) Certificat éventuel du client si le serveur demande une authentification -> CLIENT KEY EXCHANGE Le client produit un secret pré-maître (encrypted pre-master key) et le crypte avec la clé publique du certificat du serveur. Ces informations sont chiffrées une deuxième fois avec la clé publique du serveur (et non la clé publique du certificat du serveur) reçue dans le message SERVER KEY EXCHANGE. A l’aide de cette pré clé, le serveur et le client génèrent quatre clés pour la session : Server write mac secret – utilisée dans la signature des messages du serveur. Client write mac secret – pour les messages du client. Server write key – pour chiffrer les données émises par le serveur. Client write key – pour le client