Le réveil de la crypto forte

Aujourd’hui je vous entraîne sur le front de la sécurité du web, car le bouleversement qui s’y prépare va mener à la première extinction massive de (vieux) navigateurs.

Il y a bien longtemps…

Dans les années 90, la nécessité de protéger certains échanges de données sensibles des regards indiscrets est apparue sur le web. C’est principalement pour accompagner l’essor de l’e‑commerce que Netscape a mis au point HTTPS et SSL, les premiers sites de vente en ligne ont en effet rapidement eu besoin de rassurer leurs clients pour que ceux-ci renseignent leurs coordonnées et informations de carte bancaire directement sur le web. Contrairement à HTTP où les données circulent en clair, HTTPS permet de chiffrer celles-ci pour rendre impossible leur consultation par un tiers lorsqu’elles sont en transit sur le réseau. Techniquement parlant, HTTPS peut se résumer à HTTP utilisé au-dessus d’un protocole sécurisé, ce dernier pouvant évoluer indépendamment d’HTTP.

Depuis les révélations d’Edward Snowden en 2013 concernant l’ampleur des écoutes de la NSA, la généralisation et le renforcement de l’usage du chiffrement sont devenus un nouvel objectif pour certains acteurs majeurs de l’Internet. Cela prend par exemple la forme de l’initiative Let’s Encrypt qui vise à faciliter l’obtention d’un certificat X.509 qui est un élément nécessaire pour authentifier un site en HTTPS. Ou encore HTTP/2 qui en pratique nécessite TLS 1.2 (simple pis-aller en attendant TLS 1.3 pour certains).

Pour autant, c’est une mesure issue de l’univers de la finance qui m’intéresse plus particulièrement aujourd’hui, car celle-ci va annihiler un pan entier de la cryptographie considérée comme faible et participer au réveil de la crypto forte sur le web.

Il y a cadenas et… cadenas

Pour le grand public, HTTPS se résume bien souvent à la présence du petit cadenas. Dans le monde physique, il existe des normes (EN 12320 ou CEN) pour classer les cadenas par niveau de sécurité en fonction de leur résistance à certaines agressions. Sur le web, les navigateurs ne proposent rien de tel nativement et affichent bien souvent le même pictogramme cadenas, que la connexion soit sécurisée par des techniques de chiffrement récentes et a priori robustes, ou plus anciennes et sujettes à caution.

Les navigateurs distinguent cependant les certificats de type EV (Extended Validation). Un certificat EV est en général assez coûteux (compter 300 USD pour les moins chers), mais il garantit que l’émetteur du certificat a vérifié l’identité du détenteur de manière bien plus scrupuleuse (il y a des documents à fournir, des contacts téléphoniques, …). La contrepartie est un bandeau vert mentionnant le nom de l’entité authentifiée par ce certificat EV. Mais, en soi, cela ne procure aucune garantie quant à la robustesse de la connexion chiffrée, c’est juste l’authentification qui est renforcée.

En étant un peu curieux, il est possible d’obtenir plus d’informations concernant la connexion sécurisée en cours, un clic droit sur le cadenas dans Chrome permet d’afficher ceci.

Initialement, seul SSL composait le S de HTTPS. Mais de nos jours, on parle souvent de SSL/TLS voire de TLS tout court. TLS est simplement une évolution de SSL normalisée par l’IETF (Internet Engineering Task Force, qui élabore les standards Internet) sous la forme de la RFC 2246.

Les évolutions de numéro de version de TLS entraînent souvent des améliorations au niveau des processus de négociation et d’initialisation qui assurent l’interopérabilité entre clients et serveurs. Les définitions des extensions et des suites cryptographiques utilisables (composées d’un mécanisme d’échange de clés, d’une méthode de chiffrement et d’un système de vérification d’intégrité) peuvent figurer dans une autre RFC sans qu’il soit nécessaire de modifier la version de TLS ce qui offre une certaine souplesse.

La fin des années 90 a principalement été marquée par la guerre cryptographique durant laquelle les USA ont tenté d’interdire l’exportation du chiffrement symétrique reposant sur des clés de plus de 40 bits. À l’époque, le chiffrement RC4 sur 128 bits était donc réservé aux USA. Il est cocasse de constater qu’il y a quelques mois, Google, Microsoft et Mozilla ont annoncé conjointement que leurs navigateurs arrêteront d’employer RC4 début 2016 car cette méthode de chiffrement est désormais jugée trop faible.

Cela met en lumière qu’en matière de cryptographie rien n’est figé, ce qui pouvait être considéré comme raisonnablement sûr il y a 15 ou 20 ans ne l’est très probablement plus aujourd’hui.

En 2001, Juliano Rizzo et Thai Duong exposent une faiblesse relative aux blocs CBC (Cipher Block Chaining, le principe des blocs et leur chaînage est un peu trop technique… je passe donc outre les explications), à l’époque une attaque par ce biais avait été jugée impraticable. Une petite modification a toutefois été apportée à TLS 1.1 en 2006 pour corriger ce problème potentiel.

En 2011, l’attaque impraticable ne l’est plus tant que ça… Bien qu’elle reste difficile à mener, celle-ci porte désormais le nom de BEAST. Contre-mesures possibles : ne plus utiliser de chiffrement par bloc (donc exit AES-CBC pourtant considéré comme très robuste) au profit du chiffrement de flot comme RC4 ou utiliser TLS 1.1.
Mais en 2011, TLS 1.1 est loin, très loin, d’être répandu. Il faut dire qu’il n’y avait jusqu’alors que très peu de demande concernant autre chose que SSLv3 et TLS 1.0, qui fonctionnaient très bien (tout du moins en apparence).

Cet épisode a quelque peu relancé le développement et le déploiement des versions récentes de TLS et heureusement car les années suivantes sont chacune accompagnées d’une ou deux attaques plus ou moins critiques à l’encontre de SSL/TLS.

Fin 2014, l’attaque POODLE signe l’arrêt de mort de SSLv3 car cette faille facilement exploitable ne peut être comblée, la seule échappatoire possible étant de passer à TLS.

Combattre le futur, protéger le passé

De 1996 à 2014, SSLv3 a été très largement utilisé. TLS 1.0, qui a grandi dans l’ombre de son encombrant prédécesseur, n’a pris une place prépondérante que depuis quelques années. Avant 2013, l’utilisation de TLS 1.1 et 1.2 était quasi confidentielle. Il est malheureux de constater que seuls les incidents majeurs provoquent une migration massive vers des techniques plus modernes pourtant largement conseillées depuis des années. Dans le domaine de la sécurité, il conviendrait d’être un minimum proactif. Stocker des communications chiffrées, en attendant des progrès en cryptanalyse, peut éventuellement être une option pour un acteur malveillant. Tout dépend de la valeur dans le temps des informations protégées. Les cartes bancaires ont clairement une date d’expiration. Dans le cas de la vie privée ou de secrets industriels, c’est bien moins certain.

Dans un environnement client-serveur ouvert, on se retrouve facilement dans la situation où les clients ne se dotent pas du nouveau protocole car les serveurs ne le supportent pas et vice-versa. L’IETF n’a aucun pouvoir de police et ne peut en définitive rien imposer.

Mais lorsqu’un aspect économique entre en jeu les choses peuvent prendre une toute autre tournure. En avril dernier, le PCI SSC (Payment Card Industry Security Standards Council, c’est-à-dire VISA, MasterCard et les autres réseaux de cartes) a décidé d’interdire prochainement l’usage de TLS 1.0 pour mieux protéger les informations de carte bancaire. PCI DSS (Data Security Standard) constitue un ensemble de règles visant à garantir à tout moment (collecte, transfert…) la sécurité des données cartes. En cas de fuites de données impliquant un acteur ne disposant pas d’une certification PCI DSS à jour ce dernier se verrait dans l’obligation de s’acquitter de coûteuses pénalités. Cette certification est également souvent considérée comme une sorte de label de qualité, bien que ce ne soit pas sa vocation première.

Les petits sites d’e‑commerce externalisent en général cette partie en la confiant à un PSP (Payment Solution Provider) qui se doit d’être conforme PCI DSS. Les mastodontes comme Amazon qui prennent le risque de stocker les numéros de carte pour proposer du paiement en un clic se font certifier directement.

En raison de l’intensification des attaques à l’encontre de TLS, la version 3.1 de PCI DSS a introduit l’interdiction d’utiliser TLS 1.0 au-delà du 30 juin 2016³. TLS 1.1 avec certaines restrictions est encore toléré, mais TLS 1.2 est vivement conseillé.

Pour décrocher la certification PCI DSS, les serveurs et l’infrastructure de paiement doivent passer des tests de conformité. C’est donc à ce niveau que TLS 1.0 sera désactivé. Mais pour qu’une connexion sécurisée par TLS puisse s’établir, il faut que le client web (donc le navigateur) et le serveur arrivent à s’entendre lors de la phase de négociation. En pratique, le client web commence par annoncer la version du protocole SSL/TLS qu’il souhaite utiliser et le serveur s’adapte en général aux capacités du client. Maintenant que se passe-t-il lorsqu’un navigateur un peu daté (qui ne connait que les anciennes versions du protocole) s’adresse à un serveur configuré uniquement pour les versions les plus récentes ? C’est très simple, la réponse est : rien. La négociation échoue, aucune donnée ne transite, pas de HTTP, que pouic… l’analyseur de paquets réseau Wireshark permet de voir ce qui se passe assez précisément.

Pour un internaute lambda un échec de négociation TLS ressemble plutôt à ceci.

Et c’est là que l’extinction massive de navigateurs commence à se dessiner. Jusqu’à présent, les anciens navigateurs restaient peu ou prou utilisables bien que parfois confrontés à certaines dégradations visuelles. Mais l’absence de support de TLS 1.2 prend une forme bien plus définitive car il n’y a tout simplement plus de site web au bout… Ou plus sournoisement, il n’y a plus la page ou l’iframe de l’étape de paiement sur un site d’e‑commerce, ce qui constitue une très mauvaise expérience utilisateur.
Alors, oui, cela ne concerne à la base que les sites d’e‑commerce. Mais cela représente déjà un nombre très important de sites. Et beaucoup d’internautes chercheront à préserver leur capacité à réaliser des achats en ligne et adopteront pour ce faire un navigateur plus moderne.

On peut classer les navigateurs en trois catégories : ceux qui vont nécessairement disparaître prochainement car limités à TLS 1.0 maximum, ceux pour lesquels il est possible d’activer TLS 1.1 et 1.2 et enfin ceux pour lesquels TLS 1.2 est activé par défaut (mais rien ne dit que l’utilisateur ne l’a pas désactivé !).

Les navigateurs de la première colonne, bien qu’un peu anciens, représentent encore une part non négligeable des navigateurs en service. Microsoft a annoncé qu’à compter du 12 janvier 2016, seuls IE 9 sur Vista et IE 11 sur Windows 7 et 8.1 seraient encore actualisés⁴. Cela va inciter les entreprises qui utilisent encore des versions antérieures à faire le saut vers la dernière mouture pour ne pas plomber leurs audits de sécurité. Du côté d’Apple, Safari 9 est disponible sur les trois dernières versions d’OS X et iOS bénéficie de TLS 1.2 depuis un bon moment. Avec Android, la situation est bien plus complexe. Le navigateur d’origine (avant qu’il ne cède sa place au profit d’un véritable Chrome dans Android 5) ne gère éventuellement TLS 1.1+ que dans Android 4.4 KitKat… mais de nombreux constructeurs l’ont remplacé par une version maison de Chrome, notamment Samsung qui a utilisé un vieux Chrome 28 (qui connait TLS 1.1 mais pas 1.2). Bref… c’est un brin confus.

On peut espérer que les achats de fin d’année vont participer au rajeunissement des parcs informatique et mobile, et donc des navigateurs par défaut chez les particuliers. Il est toutefois très probable qu’environ 5 % des navigateurs utilisés resteront cantonnés à TLS 1.0 à l’approche de l’été 2016.

Si vous avez un site d’e‑commerce sous votre aile, il va donc falloir vous renseigner auprès de votre PSP pour savoir comment va se dérouler l’arrêt de TLS 1.0 (date, serveur de transition). Éventuellement voir avec votre hébergeur (ou administrateur système) si un passage en TLS 1.1÷1.2 exclusif est envisageable (penser à valider la configuration TLS avec SSL Labs²). Sans oublier au préalable de scruter vos logs HTTP et TLS pour jauger l’importance de la présence de vieux navigateurs parmi vos visiteurs et étudier une solution pour les prévenir qu’il est désormais temps d’abandonner leur vieux coucou car celui-ci ne répond plus aux dernières exigences de sécurité.

Pour les intégrateurs de tout bord, un rajeunissement des navigateurs sensiblement perceptible devrait se produire tout au long de l’année 2016. Champagne !

Pour autant, vous n’aurez pas fini d’entendre parler de TLS. En premier lieu à cause de TLS 1.3 (la première version de l’ère « post-Snowden »). Ensuite, le développement éventuel de calculateurs quantiques de plusieurs centaines de qubits et pouvant exploiter l’algorithme de Shor risque de sérieusement remettre en question des méthodes de chiffrement bien établies, comme RSA. Cette perspective entraîne déjà l’apparition d’algorithmes qualifiés de « post-quantique ». Ce scénario oscille encore entre l’anticipation et la science-fiction mais si les gros calculateurs quantiques deviennent une réalité la prochaine d’extinction massive de navigateurs sera largement plus apocalyptique.

Mais bien avant tout cela, si vous passez les fêtes de fin d’année chez vos parents ou grand-parents et qu’ils ont encore un vieux PC sous Windows Vista ou une tablette sous Android Jelly Bean… proposez d’y installer Firefox (ou Chrome, mais Google vient d’annoncer que ce dernier ne serait bientôt plus mis à jour sur les vieux systèmes comme Vista), cela pourrait s’avérer salutaire prochainement !

Addendum

Deux jours après la publication du présent article, le PCI SSC a fait savoir que PCI DSS 3.1 serait révisé début 2016 et reporte l’interdiction d’utiliser TLS 1.0 au 30 juin 2018, ce qui change désormais au 30 juin 2016 est l’obligation de proposer également TLS 1.1+, ceci repousse donc de deux ans la disparition des vieux navigateurs et en atténue donc largement les effets bénéfiques. Ceci constitue un énorme pas en arrière quant au niveau minimal de sécurité que l’on trouvera communément ces prochaines années sur le web. Mais cela retire une épine du pied de certains acteurs : Microsoft n’aura pas à expliquer les problèmes d’IE 9 sur Vista (le support de ce système prendra fin en avril 2017), les vendeurs d’appareils sous Android 4.x pourront continuer à écouler leurs produits pendant quelques mois encore, les cancres en sécurité resteront mauvais et la NSA va faire des économies substantielles. PCI DSS 3.1 constituait une belle opportunité d’aller franchement de l’avant et n’est désormais plus qu’un saut de puce, pour les tenants de l’adoption généralisée d’une crypto plus forte il faudra jouer sur d’autres leviers. Qu’en 2016 le web ne parvienne pas à se débarrasser d’un protocole de sécurité qui date de 1999 et dont on sait pertinemment qu’il présente des risques me laisse pour le moins perplexe…

Il y a quelque chose de pourri dans l’empire du Danemark

Shakespeare