HTTP/2 : attention, peinture fraîche !

Magazine
Marque
MISC
Numéro
88
Mois de parution
novembre 2016
Domaines


Résumé

Standardisé en mai 2015 [RFC7540, RFC7541], HTTP/2 fait depuis l'objet de nombreuses campagnes « marketing » de la part de Google, Cloudflare ou Akamai. En contre-courant de cette vague (trop ?) enthousiaste se dressent des voix tentant de tempérer les prétendues améliorations en performance provenant de bancs de test biaisés. La communauté sécurité n'est pas en reste, soulignant que HTTP/2 n'est pas le remplaçant de HTTP/1.1 [Snort], mais bien un nouveau protocole à part entière dont la complexité est significative et les enjeux encore mal compris. Cet article détaille les défauts de HTTP/1.1 présentés comme justificatifs pour HTTP/2. Il dresse ensuite un portrait de ce nouveau protocole et de certaines réserves à son encontre.


1. HTTP/1.1, le dinosaure du web

Spécifié pour la première fois en 1999 avec la RFC2616 [RFC2616], HTTP/1.1 est parfois considéré comme un dinosaure. Il est vrai que si les RFC sont immuables, l’écosystème du Web, en mutation permanente, a bien évolué depuis lors. HTTP/1.1 résiste néanmoins aux affres du temps grâce à sa capacité à être étendu, ainsi qu'à la relative « flexibilité » que la communauté web s'accorde vis-à-vis des normes, qu'elles proviennent du W3C ou de l'IETF. Ce sont ainsi plusieurs dizaines de RFC qui sont venus enrichir le substrat de la RFC 2616 avec des mécanismes d'authentification (authentification basique, Kerberos...), la capacité de gérer des systèmes de fichiers (WebDav) ou encore de nouveaux en-têtes (Origin, Cookie2, Access-Control-Allow-Origin…).

Malgré ses qualités, le texte normatif originel n'est pas exempt de défauts rédactionnels et techniques. Ainsi, en 2014, une longue série de RFCs, de RFC7230 à...

Cet article est réservé aux abonnés. Il vous reste 97% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite
Références

[Snort] Billet traitant de la prise en charge de HTTP/2 : http://blog.snort.org/2015/02/snort-30s-new-httpinspect-preprocessor.html

[draft-nottingham] Brouillon IETF pour l’amélioration de la prise en charge du pipelining HTTP : https://tools.ietf.org/html/draft-nottingham-http-pipeline-01

[FrontEndOptim] Billet sur l’optimisation des performances avec HTTP/1.1 seul : http://csswizardry.com/2013/01/front-end-performance-for-web-designers-and-front-end-developers/

[QUIC] Site officiel détaillant le protocole QUIC : https://www.chromium.org/quic

[RFC2616] RFC originelle de HTTP/1.1 : https://www.rfc-editor.org/rfc/rfc2616.txt

[RFC7540] RFC de HTTP/2 : https://www.rfc-editor.org/rfc/rfc7540.txt

[RFC7541] RFC de HPack : https://www.rfc-editor.org/rfc/rfc7541.txt

[CRIME] Planches de l’attaque CRIME : https://goo.gl/wCLTR5

[CloudflareTest] Test de performance comparatif de Cloudflare : https://www.cloudflare.com/http2/

[AkamaiTest] Test de performance comparatif d’Akamai : https://http2.akamai.com/demo

[TroyHuntTest] Blog de Troy Hunt sur la performance de HTTPS : https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/

[CloudflareBlog] Blog de Cloudflare : Bonnes pratiques HTTP/2 pour les développeurs web : https://blog.cloudflare.com/http-2-for-web-developers/

[Mifsud] Billet sur les performances HTTP/2 avec un impact mitigé : https://99designs.com.au/tech-blog/blog/2016/07/14/real-world-http-2-400gb-of-images-per-day/

[BOSSERT] Comparaisons et attaques sur le protocole HTTP2 : https://www.sstic.org/2016/presentation/comparaisons_attaques_http2/

[Yahoo] Billet sur les vulnérabilités HTTP/2 découvertes par Yahoo : https://yahoo-security.tumblr.com/post/134549767190/attacking-http2-implementations

[Imperva] HTTP/2 : In-depth analysis of the top four flaws of the next generation web protocol : https://www.imperva.com/docs/Imperva_HII_HTTP2.pdf

[Kamp] HTTP/2.0 — The IETF is Phoning It In : http://queue.acm.org/detail.cfm?id=2716278



Articles qui pourraient vous intéresser...

La téléportation, de la fiction au SDN

Magazine
Marque
MISC
Numéro
114
Mois de parution
mars 2021
Domaines
Résumé

L’art de se téléporter n’est plus réservé au cinéma ! Suite au développement de nouveaux paradigmes tels que le SDN, facilitant le déploiement de firewalls, la sécurité du plan de données a considérablement augmenté. Mais est-il possible d’éviter ces points de passage pour exfiltrer des données entre deux extrémités d’un réseau ? Au lieu de chercher un trou dans le mur, ne serait-il pas plus simple de trouver un moyen de le contourner ? C’est là l’ambition des techniques de téléportation. Nous explorerons les différentes techniques exploitant ce concept, puis nous reproduirons l’une de celles-ci sur un contrôleur SDN, ONOS.

Avec le Spanning Tree Protocol, suis-je en sécurité dans mon réseau ?

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines
Résumé

Dans le cadre des hors-séries sur les retours aux fondamentaux, cet article aura comme sujet le protocole STP (Spanning Tree Protocol). Inventé en 1985 par Radia Perlman, il permet principalement d’assurer une liaison réseau redondante et sans boucle. Ce protocole étant primordial au sein d’un réseau de moyenne à grande envergure, s’il n’est pas correctement configuré, cela pourra alors permettre à des attaquants de compromettre le réseau.

Détection d'anomalies par ACP

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Domaines
Résumé

Retour de vacances. L’analyse du SIEM après un mois d’absence montre que dix incidents ont été déclenchés sur la base des alertes automatiques et ont pu être gérés convenablement par la chaîne de traitement d’incidents. Tout est-il sous contrôle ? Un analyste aimerait rapidement s’en assurer en complétant cette supervision par sa propre analyse du mois écoulé. Mais par où commencer ? Il est inenvisageable de regarder un mois de logs « rapidement » et d’autant plus quand on ne sait pas précisément ce que l’on cherche… Une solution possible est de recourir à des outils statistiques qui permettent d’identifier des périodes d’activité atypiques sur lesquelles concentrer son analyse. L’analyse en composantes principales (ACP ou PCA en anglais) est une méthode statistique qui peut répondre relativement efficacement à cette problématique. L’article présente cette méthode et son apport dans la détection d’anomalies, en prenant comme exemple l’analyse de flux réseaux.