SSL est mort !

Bon, aujourd'hui c'est la fête nationale, alors je me dois de faire une activité typiquement française. Je vais râler.

SSL est mort

Je vais râler contre tous ces gens qui disent sécuriser leur application avec SSL, qui parlent de certificats SSL, de connexions SSL. Pourquoi donc ? C'est bien de chiffrer ses communications. Mais SSL est mort, troué, perclus de failles. On a trois versions de SSL : la v1, uniquement théorique et jamais mise en oeuvre (parce que bien trop bourrée de failles), la v2 et la v3. Et devinez quoi ? Elles sont toutes trouées.

Mais alors comment on fait ? On utilise TLS. "Ouais mais c'pareil !" Alors oui, du point de vue de l'utilisation, ça peut paraître similaire. Y'a le petit cadenas vert en haut, donc c'est safe, et c'est écrit HTTPS. Oui, mais SSL (et certaines versions de TLS d'ailleurs) n'assurent pas un niveau de sécurité convenable pour les échanges. Et tant que les gens parleront de "SSL" pour parler de connexions chiffrées, les dev et admin systèmes pas formés à la sécurité utiliseront SSL. On le voit tous les jours sur plein de sites : un simple scan SSL nous révèle du SSLv3, voire du SSLv2.

Donc maintenant que j'ai râlé, on va passer à une activité vachement moins française : proposer des solutions.

Alors, on utilise quoi ?

Il y a 5 versions possibles : SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2. SSLv2 est victime de DROWN, SSLv3 de POODLE, et TLS1.0 et certaines version de TLS1.1 à BEAST . Ça limite un peu le choix ! Conclusion : TLSv1.2, c'est bon, mangez-en ! (Au passage, on notera le talent des experts en sécu info pour trouver des accronymes pour leurs noms de failles)

Et les ciphersuites dans tout ça ?

Ah, les suites de chiffrement. Quels sont les ensembles d'algorithmes utilisés pour chiffrer les données ? Il y en a plein, et le choix peut être difficile. Alors il y a une première solution simple : virer toutes les chaînes qui contiennent des éléments pas assez forts. Donc on va dégager partout où on voit :

• DES (Parce qu'à ce niveau, c'est tellement simple à casser que c'est plus de la crypto)
• 3DES (C'est moins pire que DES. Mais quand même)
• RC4 (Troué !)
• SHA (SHA tout court correspond à SHA1 qui est trop faible, SHA256 et + sont fiables)
• MD5 (Trop de risques de collision)
• NULL (Parce qu'un chiffrement NULL, ben, ça chiffre pas...)

Déjà ça fait un peu de ménage. Ensuite, il faut utiliser uniquement les suites proposant la Perfect Forward Secrecy (PFS). Qu'est ce que ça veut dire ? Concrètement : avant d'échanger vos données, le client (le navigateur par exemple pour du web) et le serveur se mettent d'accord sur une clef de chiffrement temporaire qui sera jetée ensuite. L'avantage, c'est que si quelqu'un vole la clef du serveur, il ne pourra pas déchiffrer vos communications puisqu'il n'aura pas la clef temporaire. De la même manière, s'il vole la clef temporaire, les échanges passés et futurs sont protégés, puisque n'utilisant pas la même clef temporaire (bah oui, sinon elle serait pas temporaire). C'est les grandes lignes de la PFS. Pour en savoir plus je vous invite à lire l'article wikipedia sur la confidentialité persistante.

Comment on reconnaît les suites proposant du PFS ? C'est pas compliqué, c'est toutes celles qui utilisent Diffie Hellman Ephemeral (Diffie-Hellman est le protocole pour déterminer la clef temporaire). Donc les chaînes commencent par DHE ou ECDHE (pour Elliptic Curve DHE, qui utilise les courbes elliptiques). Tout ce qui ne commence pas par DHE ou ECDHE, on vire !

Eh ben déjà, il reste plus grand chose.

Pour le fignolage, on peut autoriser uniquement les suites utilisant AES(128|256) en mode GCM (Galois Counter Mode). Rien à voir avec Counter Strike. Mais les mode CBC sont faillibles à POODLE, donc on garde que si y'a GCM dedans.

Sur mon ordi portable, il me reste donc 6 suites de chiffrement autorisées sur les 121 utilisables supportées par ma version d'openssl. Ça fait un peu de ménage. Voici les grands gagnants :

DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384

Donc TLSv1.2, et autoriser uniquement ces suites... Mais pouquoi tout le monde ne le fait pas ?

La compatibilité

J'ai dit le gros mot. Et je vais même en dire un deuxième pour que ça soit fait : "Internet Explorer". Parce que quand on parle TLS, souvent c'est au sujet du web et de HTTPS, puisque c'est ça qui est le plus visible pour le grand public. Et le problème c'est que les navigateurs les plus anciens ne sont potentiellement pas capable de "parler TLSv1.2" ou (plus probablement) d'utiliser les suites de chiffrement proposées au dessus. Et ne peuvent donc pas accéder au site.

Mais pourquoi ce troll gratuit sur Internet Explorer ? Tout simplement parce que les deux autres navigateurs principaux, Chrome et Firefox, disposent tous les deux d'un outil de mise à jour automatique activé par défaut et transparent pour l'utilisateur. Et qui dit navigateur à jour, dit suites supportées.

Les versions raisonnablement récentes d'IE sont tout à fait capables de supporter ces suites de chiffrement (je prends à temoin les quelques visiteurs de ce site qui utilisent IE). Mais Tatie Germaine, qui a son ordinateur (avec un petit naperon brodé posé sur l'écran cathodique) sous Windows XP SP1 et Internet Explorer 6, ne pourra pas elle.

A vous de vous poser la question : quel est mon public, quel est mon enjeu de sécurité ?

Si votre public est restreint et plus susceptible d'être à jour, a priori pas de soucis. C'est le cas de ce blog, qui attire plutôt un public technophile et à l'aise avec l'informatique. Donc des gens qui auront probablement un navigateur à jour. De la même manière, le fait que les gens ne puissent pas accéder au site n'est pas critique. Je perds des visiteurs, mais leur vie ne va pas être bouleversée parce qu'ils n'auront pas lu ma superbe prose.

Quand vous devez toucher un public large, c'est plus embêtant. Google, par exemple. Si Tatie Germaine peut pas utiliser Google (même si elle sait pas ce que c'est, mais son neveu l'a mis en page d'accueil et lui a dit de taper dans la barre), c'est plus embêtant. En revanche, les données qui transitent par Google (on parle ici de l'utilisation simple du moteur de recherche, sans être connecté) ne sont pas extrêmement critiques. Il s'agit de vie privée, certes, mais pas forcément de secret d'Etat. On peut donc tolérer l'utilisation d'une sécurité qui ne soit pas à l'état de l'art, même si on privilégiera les solutions de meilleure qualité si elles sont disponibles.

Il y a un troisième exemple qui est plus gênant. Le site de ma banque, qui me permet de relever mes comptes en ligne. Le public est large, il faut que Tatie Germaine puisse relever ses comptes (son neveu lui a montré, c'est drôlement pratique). Mais il ne faut pas que n'importe quel virus qui traîne sur le PC de Tatie Germaine (qui n'a pas d'antivirus évidemment) puisse déchiffrer le trafic pour voler des identifiants. On a un enjeu de sécurité qui est très fort.

Pour l'instant, au vu des résultats sur les scans de sécurité, les banques ont fait le choix de se rendre accessibles au plus grand nombre (le choix était peut être inconscient et dû à l'incompétence des administrateurs du site... chut).

Mon avis personnel est que c'est une erreur. Je préfère que ma banque me dise "Désolé, vous utilisez un navigateur trop ancien, pour la sécurité de votre argent je ne peux pas vous laisser accéder à vos comptes en ligne. Vous pouvez télécharger un navigateur récent et plus sécurisé ici où là". D'accord, c'est emmerdant pour Tatie Germaine. Mais si on lui explique que sinon elle pourrait se faire voler son argent, je pense qu'elle comprendrait (et qu'elle s'empresserait de demander à son neveu de lui "mettre à jour l'internet"). Effet positif pour l'image de la banque : elle prend soin de l'argent de ses clients (on ne sortira pas cette phrase de son contexte merci). Double effet kiss-cool : On améliore le niveau de sécurité global en poussant les gens à mettre à jour leur navigateur. C'est-t'y pas bô ?

Bilan

Le débat sécurité/accessibilité n'est pas prêt de se résoudre. D'où l'importance de l'approche "public/enjeux", pour adapter votre niveau de sécurité à votre cas précis. Et cette affirmation ne concerne pas que TLS.

Et par pitié. Arrêtez de parler de SSL.

(Et de crypter. Et de "la" wifi. Et de "guif". Et de...)