La bombe à retardement ALPN/NPN

Sur le web de nos jours, Chrome est pratiquement leader du marché. Depuis quelques mois, ils sont assez agressifs dans la gestion des nouveaux protocoles, poussant dehors tout ce qui n’est pas résolument à la pointe.

Le 15 Mai 2016 sera une petite révolution si rien ne change

 

Google annonce donc cesser de supporter SPDY dans Chrome. Ils annoncent que “seuls 5% du web” (sic) utilise SPDY, donc c’est pas gave si on retire la prise à 5% du web finalement. Après tout, qui utilise des sites comme LinkedIN – qui sont toujours en SPDY a l’heure où je tape ceci. 🙂

Non plus sérieusement, je sais bien que le browser va “retomber” en HTTP 1.1 – mais tout de même, Google Chrome va donc envoyer promener les protocoles “rapides” de 5% du web qui sont très légèrement à la traine, dont des très grands noms comme LinkedIN, et ce dans moins de deux mois.

Je suis pas sûr que l’info soit passée chez grand monde…

Plus insidieux encore, et je ne vois que quelques rares pages qui en parlent sur le web ; Google va non seulement jeter SPDY mais également NPN, protocole de négociation de… protocoles SSL. Ce protocole est surtout le seul disponible dans OpenSSL<1.0.2. Et ceci en faveur de ALPN, qui lui nécessite OpenSSL 1.0.2 au minimum.

Hors toutes les distributions linux LTS et Stable sont actuellement en OpenSSL 1.0.1. Et ca n’a pas l’air de vouloir changer de si tôt. En clair, cette fois c’est l’intégralité des sites HTTP/2 alimentés par ces versions de OpenSSL à qui Chrome va refuser de parler. Il est donc, à l’heure où j’écris ceci et sur un serveur Linux de type LTS/Stable (CentOS 7, Debian Jessie, Ubuntu Trusty, etc), impossible de créer un serveur HTTP/2 qui soit compatible avec Chrome à partir du 15 Mai 2016, si vous ne compilez pas vous même votre serveur Web (nginx ou apache), ou tentez un backport “unstable” de plusieurs librairies.

Google prétend ici que 99% (sic!) des sites surfés par Chrome en HTTP2 supportent ALPN. Je ne sais pas d’où Google a été tirer une statistique pareille, mais elle ne correspond pas à mes observations.

Google avait déjà brièvement fait cette modif par le passé, mais constatant qu’ils venaient de tuer le protocole HTTP/2 sur les trois quarts des serveurs de la terre (rares sont les serveurs de prod en “unstable/testing”), ils ont fait marche arrière. J’ose espère qu’ils feront pareil encore une fois, ou qu’ils ont le bras assez long que pour “pousser” un “backport ALPN” dans OpenSSL1.0.1 dans toutes les distributions de la terre d’ici Mai.

A bon entendeur…

4 réflexions au sujet de « La bombe à retardement ALPN/NPN »

  • Nonon, d’ailleurs ce serveur auquel tu parles est lui même en HTTP/2 et sans support ALPN puisqu’il tourne sur un distro stable…

    Je vais backporter OpenSSL 1.0.2.

    C’est vraiment gros comme une maison, je pense qu’ils se rendent pas compte de l’impact et qu’ils vont encore annuler cette decision… (Ou alors pousser un backport de la fonction ALPN dans openSSL 1.0.1 mais ils serait temps de se dépecher…)

    On peut très bien, et c’est même la façon la plus courante de faire, installer HTTP/2 sur un distro stable soit en ajoutant les repo de NGINX.
    Et si tu fais ca, ben ton HTTP/2 sautera en Mai 2016.

    Ce test montre ce qui support ALPN ou pas; utile dans le contexte de mon article;
    https://tools.keycdn.com/http2-test

  • Si tu prends “Yahoo.com” dans ce test, ca met par exemple HTTP2 supporté mais ALPN non supporté…

    En résumé ; je pense qu’ils ont pété un cable chez Chromium.

  • Ah je pensais avoir lu ça, du coup j’avais mis de côté le passage de mes sites en HTTP/2 parce que je n’avais pas envier d’aller chercher OpenSSL 1.0.2 dans les dépôts testing. Pour le coup ce n’était peut-être pas plus mal que j’ai mis ça de côté pour le moment ^_^

    Merci pour l’info en tout cas 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *