BT

Renforcer HTTP

par Mark Little , traduit par Julien Delhomme le 21 janv. 2014 |

Nous avons déjà eu l'occasion de mentionner le travail effectué par l'HTTPbis Working Group sur la définition d'HTTP 2.0. Mark Nottingham, le président du groupe de travail, a récemment posté son point de vue personnel sur la réflexion menée autour des exigences de sécurité relatives au protocole.

Récemment, un des sujets dont on a le plus parlé dans la communauté s'intéressant à Internet et ses protocoles a été de savoir si HTTP/2, la dernière version du protocole du Web, allait rendre obligatoire, encourager, ou s'il allait même aborder le sujet de l'utilisation du chiffrement, en réponse aux faits de surveillance de masse révélés au monde par Edward Snowden.

Mark retrace brièvement l'historique des travaux jusqu'à aujourd'hui, particulièrement en ce qui concerne SPDY et la sécurité.

Lorsque Mike (Belshe) et Roberto (Peon) nous ont amené SPDY (bien avant que "Snowden" devienne un nom connu du public), ses implémentations requéraient déjà l'utilisation de TLS pour le chiffrement. C'était à la fois pour des raisons pragmatiques (il est très difficile d'introduire une nouvelle version d'HTTP quand il y a au milieu des choses qui ne savent rien de celle-ci) et pour des raisons plus profondes.

À ce moment, le groupe s'intéressait à des cas d'utilisation qui ne nécessitaient pas de sécurité particulière. De ce fait, le rendre obligatoire ne mettait pas tout le monde d'accord...

[...] ni la spécification, ni notre charte ne disent quelque chose à ce sujet. La compréhension tacite était que nous allions faire en sorte qu'HTTP/2 puisse être utilisé au-dessus de connexions chiffrées et non-chiffrées et que les implémentations décideraient quoi supporter.

Avec l'arrivée de Snowden et les révélations sur XKeyscore, il y eut un tournant significatif au sein de l'IETF. Une session exceptionnelle a été tenue à l'occasion d'une réunion du groupe de travail à Berlin, et a résulté en un consensus fort pour améliorer la sécurité d'HTTP à travers le recours à plus de chiffrement. Cela a généré de nombreuses discussions au sein de l'IETF au cours des mois et des réunions qui suivirent :

Il n'y avait aucun doute que nous partagions l'objectif d'aller de l'avant dans l'utilisation de TLS avec HTTP - et ainsi de protéger contre la surveillance et d'autres types d'attaques. Cependant, les questions telles que la façon de faire, la manière de remplir au mieux les objectifs ou les compromis appropriés, ont donné lieu à de nombreux débats et désaccords.

Mark explique que les développeurs de Chrome et de Firefox se sont clairement montrés favorables à ne supporter HTTP/2 que s'il était protégé par TLS. Il a également parlé aux développeurs d'autres navigateurs et à des experts en sécurité pour formuler ce qu'il estimait être la meilleure façon d'avancer :

[...] dans le cas courant de la navigation Web, les serveurs HTTP/2 devront utiliser TLS s'ils veulent interopérer avec le plus grand nombre de navigateurs, en suivant exactement la même approche de Mike et Roberto avec SPDY. Cependant, dans la spécification du protocole, nous n'avons pas à rendre l'utilisation de TLS obligatoire.

Mark donne ensuite d'autres détails sur sa proposition et explique que, alors que certains groupes sont attachés à avoir plus de sécurité, d'autres pensent qu'il n'est pas approprié pour l'IETF de rendre obligatoire le chiffrement pour tous les cas d'utilisation d'HTTP/2. Dans ces circonstances, il est difficile pour l'IETF d'arriver à une décision, particulièrement sur des problèmes avec un aspect "politique", comme celui-ci. Selon Mark :

Il s'agit d'une décision politique, non pas parce que cela classe le gouvernement comme "attaquant", mais parce que HTTP est un protocole déployé, impliquant de nombreux acteurs, comme des éditeurs de proxy, des opérateurs réseau, des entreprises et leurs firewalls, etc. En exigeant un chiffrement pour HTTP/2, tous ces acteurs se trouveraient démunis.

Cependant, Mark pense que l'IETF et le groupe de travail peuvent faciliter les discussions qui sont nécessaires de mener autour des avantages et des inconvénients des différentes options, tout en assurant la flexibilité et la précision dans le protocole HTTP/2.

Par exemple, dans la conception actuelle d'HTTP, la décision d'utiliser un chiffrement ou non est entièrement laissée au serveur. La seule chose que l'utilisateur puisse faire est d'observer si une URL est en "HTTP" ou en "HTTPS" (ou éventuellement repérer une icône le signalant) et décider s'il continue de surfer ou non. Un Web plus équilibré devrait permettre aux clients d'influencer la décision, avec la promesse d'un avantage quelconque pour encourager les serveurs à supporter le chiffrement, par exemple en ne supportant HTTP/2 qu'avec chiffrement, comme font Chrome et Firefox.

Ici, la décision est faite par les éditeurs de navigateurs plutôt que par le standard. Et ensuite alors ? Et bien une réunion de l'HTTPbis Working Group est à venir. Elle se tiendra à Zurich et Mark a fait appel à des propositions afin de résoudre le problème de fond :

Plusieurs éditeurs de navigateurs ont affiché leur intention d'implémenter uniquement HTTP/2 au-dessus de TLS pour le trafic "ouvert" sur Internet. Ils peuvent le faire aujourd'hui en implémentant HTTP/2 que pour les URIs en https://. Les sites souhaitant utiliser le nouveau protocole doivent appliquer une redirection pour les URIs en http://, par exemple avec HSTS pour établir cette modification. En tant que tel, nous n'avons pas forcément à spécifier cela comme une exigence (par exemple avec un DOIT ou un NE DOIT PAS). Les sites qui veulent utiliser le nouveau protocole avec ces navigateurs implémenteront le modèle décrit ci-dessus. Cependant, pour promouvoir l'interopérabilité, nous pourrions proposer des lignes directrices ou même quelques conditions requises pour cadrer tout cela. La démarche ici est précisément de collecter des propositions pour de tels textes.

Ceci signifierait que le standard HTTP/2 ne rendrait pas obligatoire TLS, mais que les implémentations au niveau des navigateurs pourraient le faire. Toutefois, comme le fait remarquer Mark, ces implémentations pourraient être l'objet de pressions pour permettre aux proxies des entreprises d'inspecter le trafic, etc. Si cela se produit, il est important que les réponses apportées soient coordonnées pour préserver l'interopérabilité du standard. Mark conclut en rappelant qu'aucune décision n'a été encore prise et qu'il est toujours possible d'aboutir à un résultat différent. Le groupe est plus que jamais ouvert à entendre les opinions de chacun sur ce débat. Après tout, il y a de fortes chances que les décisions prises par l'IETF Working Group aient un impact sur beaucoup d'entre nous dans le futur.

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT