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.

⚠ En raison d’une évolution de dernière minute, certains changements prévus pour 2016 n’auront finalement lieu qu’en 2018.
Consulter l'addendum pour plus de précisions.

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.

Barre d’icônes de Netscape 4

Netscape Navigator 4 présentant un cadenas verrouillé, comme en 1997.

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.

Un cadenas endommagé et un autre intact

Identifier une solution de sécurité qui a fait son temps peut être plus simple dans le monde réel.

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.

Une barre de navigation avec le bandeau vert dédié aux certificats EV

Le certificat EV de la fondation Mozilla est clairement mis en exergue par… Chrome.

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.

Le détail de la connexion chiffrée

Chrome indique que ce site utilise une méthode de chiffrement obsolète (ce qui n’est pas très rassurant) et que la connexion repose sur TLS 1.0, pour autant dans la barre d’adresse il y a un cadenas tout ce qu’il y a de plus standard.

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.

SSL-TLS : évolution dans le temps et principales attaques de 1995 à nos jours

Depuis TLS 1.0 en 1999 deux nouvelles versions sont apparues : 1.1 en 2006 et 1.2 en 2008, la version 1.3 est en préparation depuis quelques années.

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).

Graph représentant le taux d’adoption des différentes versions de SSL-TLS côté serveur

Données SSL Pulse1 d’avril 2012, SSLv2 est encore proposé par un tiers des sites ! SSLv3 et TLS 1.0 sont eux utilisés sur plus de 99 % des sites du panel (top 200 000 d’après Alexa), enfin TLS 1.1 et 1.2 arrivent péniblement à 1 %.

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.

Formulaire de saisie des informations de carte bancaire

Dans le cadre du web, PCI DSS concerne toute la « machinerie » derrière les formulaires de paiement, ceux où les clients saisissent leur numéro de carte et le cryptogramme de sécurité.

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 20163. 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.

Traces réseau de connexions SSL-TLS

Dans le premier cas, un client web un peu ancien fait deux tentatives (une fois en TLS 1.0 et une fois en SSLv3) pour établir une liaison sécurisée. Mais le serveur auquel il s’adresse n’autorise que l’usage de TLS 1.2. Il n’obtient donc en retour que des alertes d’erreurs fatales. Dans le second cas, avec un client web plus récent le serveur répond positivement à la demande en TLS 1.2 et on voit, entre autres, qu’il transmet son certificat dans la foulée.

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

Le laconique message d’erreur « Internet Explorer ne peut pas afficher cette page Web »

Internet Explorer 9 sur Windows Vista perdu face à un serveur configuré exclusivement pour une version de TLS qu’il ne connait pas.

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.

Les options Internet d’IE 9 (Vista) et IE 11 (Windows 7)

La subtile différence entre Internet Explorer sur Windows Vista et Internet Explorer sur Windows 7… aucune trace de TLS 1.1/1.2 sur Vista. IE ne contient pas lui-même le code utilisé pour SSL/TLS mais repose sur les capacités du système d’exploitation sous-jacent.

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é !).

TLS 1.0 maximum TLS 1.1+ activable TLS 1.2 d’origine
IE 6 et 7 IE 8, 9, 10 (Windows 7) IE 11
IE 8 et 9 (Vista) IE 10 (Windows 8) Edge (Windows 10)
Safari 4, 5, 6 (OS X) Safari 7, 8, 9 (OS X 10.9+)
Safari 4, 5 (iOS 4) Safari 5, 6, 7, 8, 9 (iOS 5+)
Chrome 21 et moins Chrome 22 à 29 Chrome 30 et plus
Firefox 23 et moins Firefox 24, 25, 26 Firefox 27 et plus
Opera 16 et moins Opera 17 et plus
Android 4.3.x et moins Android 4.4.x Android 5 et 6 (Chrome)

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és4. 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.

Évolution de la part de marché de Chrome 28 sur tablette et mobile, encore à 2,5 % fin 2015.

La part de marché de Chrome 28 sur tablette et mobile d’après Net Market Share, le Samsung Galaxy S4 mini, entre autres, contribue à son maintien alors que Chrome 27 et 29 sont eux pratiquement à zéro.

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.

Animation représentant le taux d’adoption des différentes versions de SSL-TLS de 2013 à nos jours

Depuis quelques mois les données collectées par SSL Pulse indiquent que TLS 1.0 a entamé un lent repli (de 99,7 à 98,8 % un frémissement donc), alors que la croissance de TLS 1.1 et 1.2 reste soutenue, ces versions sont désormais proposées par environ 70 % des sites.

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 Labs2). 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

Frédéric Kayser

À propos de Frédéric Kayser

Vieux de la veille, évangéliste crypto à temps perdu, anime @TLSv12 sur Twitter.

Vous pouvez partager cet article sur Facebook, Twitter ou Google+.

Faites un don pour soutenir l'association Les B-A des Satellites

L'association Les B-A des Satellites aide à offrir une école aux enfants de Niellé en Côte d'Ivoire.

Les fonds récoltés vont directement sur le compte PayPal de l'association. En cliquant sur le bouton « Faire un don » ci-dessus, vous allez être redirigé vers PayPal. Vous n'êtes pas obligés de créer un compte PayPal pour faire un don.

4 commentaires sur “Le réveil de la crypto forte

  1. gmesnard, le mercredi 16 décembre 2015 à 15:16

    La sécurité web expliquée clairement ! Merci Frédéric, j'y vois plus clair maintenant entre SSL et TLS ;)

  2. Nicolas Chevallier, le samedi 19 décembre 2015 à 21:47

    Excellent article que je me suis permis de repartager sur WRI : http://forum.webrankinfo.com/vers-fin-ie6-juin-2016-t184728.html

    J'ai appris beaucoup sur les subtilités derrière le HTTPS, mais surtout le prochain abandon forcé de IE7 (joie!).

  3. Nico, le dimanche 20 décembre 2015 à 08:40

    L'addendum n'enlève rien :
    - à la qualité de l'article (merci pour tous ces détails)
    - et au fait qu'il faudra de toutes manières y passer à un moment ou à un autre.

    Bref, c'est reculer pour mieux sauter.

    Saurais-tu de quel type sont les certificats Let's Encrypt à tout hasard ?

  4. Random_elvb, le dimanche 20 décembre 2015 à 17:10

    Salut,

    @Nico : Le choix de l'autorité de certification n'a aucun rapport avec l'algorithme de chiffrement utilisé par le serveur.
    Un certificat Let's Encrypt peut-être utilisé pour faire du SSLv3 ou du TLSv1.2.

    Firefox mobile est toujours maintenu pour les anciennes versions d'Android (2.2 ou 2.3) et prend en charge tout les protocoles récents.

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter l'auteur de l'article, les autres participants à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.