SSL/TLS: fiable ou faible?

Le SSL/TLS est une manière particulièrement efficace pour protéger les communications sur internet. L'application de SSL/TLS la plus connue est HTTPS.
Je propose un petit tour d'horizon sur la sécurité liée à SSL/TLS en me basant quasi essentiellement sur l'application de ce protocole sur HTTPS. Les conclusions restant généralement vraies pour les autres protocoles (IMAPs, POP3s, etc..).

L'échange HTTPS permet d'une part de chiffrer la communication entre un serveur et un client, d'autre part d'authentifier le serveur distant, et éventuellement d'authentifier le client (Par exemple, le site des impots français authentifie le client distant).

Les pirates souhaitant accéder à des informations protégées par SSL/TLS ont donc deux moyens; s'attaquer à HTTPS tout d'abord, ensuite chercher à contourner HTTPS.

1/Attaquer HTTPS
Une communication chiffrée HTTPS débute par un échange cryptographique (RSA ou DiffieHelmann) permettant d'échanger une clé de chiffrement symétrique.

Un pirate peut s'attaquer au protocole de chiffrement symétrique. Généralement, il s'agit d'AES. Le brute force sur AES est ajourd'hui hors de portée. Un calcul rapide mettant en oeuvre 1 milliards de machines, 32 cores à 30GHz, sachant calculer un bloc par cycle (ce qui dans l'ensemble semble exagéré) mettra à peu près 6 milliards d'année pour tester 2^127 clés AES.
La cryptanalyse actuelle indique une baisse de niveau d'AES-256 à 2^119 et AES-192 à 2^176. AES-128 n'est pas touche.

L'autre option consiste donc à attaquer le RSA afin de déchiffrer cette clé symétrique. Les clés RSA font aujourd'hui au minimum 1024bits, et la plupart 2048bits. Le site des impôts cité plus haut utilise une clé publique de 2048bits.
Le 12 janvier 2010, un groupe de recherche explique avoir réussi un challenge consistant à casser une clé RSA-768. Contrairement à ce qu'on a pu lire, RSA-768 n'est pas cassé, pas plus que RSA, c'est seulement une clé qui a été cassée. La clé se lit ici. Il a fallu deux ans et demi de calculs pour parvenir à ce résultat. Même si la loi de Moore veut que les machines calculent de plus en plus vite, je pense qu'une clé de 2048 permet d'être tranquille un certain temps. Le site keylength donne les tailles de clés nécessaires selon une durée de conservation souhaitée.

D'autres méthodes permettant de casser plus rapidement une clé RSA existent, néanmoins, elles imposent un accès privilégié au CPU afin de pouvoir le monitorer pendant le calcul RSA.

La solidité de RSA repose sur l'impossibilité de factoriser facilement un très grand nombre, problème mathématique qui n'est toujours pas résolu.

Toutefois il a existé quelques temps une attaque protocolaire sur SSL/TLS, basée sur la renegociation des clés de session. J'avais blogué sur celle-ci. C'est aujourd'hui corrigé par une RFC.

2/ Contourner HTTPS
Le pirate va donc s'ingénier à contourner HTTPS s'il veut accéder aux informations souhaitées. Et là, il existe plusieurs méthodes efficaces.

Tout d'abord, le pirate peut tenter des attaques en deux temps. Tout d'abord il peut compromettre le poste client, lui faire ajouter dans son navigateur des Browser Helper Object. Ces BHO vont ajouter dans des formulaires bancaires d'autres champs demandant le numéro de carte bancaire, date de péremption etc.. afin de les renvoyer vers le pirate. Les utilisateurs sont peu méfiants, ils sont bien sur le site de la banque, HTTPS est fonctionnel. (Je n'ai plus l'URL montrant ces attaques, un botnet l'utilisait comme charge active).

Ensuite, le pirate peut attaquer le serveur et casser le générateur aléatoire. Les clés de chiffrement symétriques sont générés aléatoirement. Si elles ne le sont pas, un pirate pourra facilement décoder tous les messages. J'ai vu cette méthode sur le blog de Julien Tinnes lors d'un de ses posts. Appelée 'Debian Emulation' pour une raison amusante liée aux déboires de debian quant à la qualité de leurs aléas, elle consiste à faire:
ln -s /dev/zero /dev/urandom

Ou alors, le pirate peut envoyer les requêtes du client sur une machine maîtrisée, machine qui reproduira la site officiel afin que le client envoie de lui-même ses informations. Pour se faire, plusieurs moyens:
-s'appuyer sur des failles DNS (chercher Kaminsky DNS sur google par exemple)
-s'appuyer sur des failles BGP (pour rediriger le trafic sur un réseau maitrisé)
-faire du phishing
Pour le phishing il existe la campagne de mail, ou plus dernièrement les IDN ou l'internationalisation des noms de domaines. Qui irait confondre paypal et raural?

Il reste le problème mineur des sites qui sont http et pas https. Mais disposer d'un site https qui ne remonte pas d'alerte visible à l'utilisateur (petit cadenas fermé, couleur dans la barre d'adresse) est toutefois possible.
-Il est possible de générer un vrai-faux certificat. (Tant qu'on paye, les CA fournissent des certificats)
-La faille MD5 a permis de posséder un certificat de sous-CA parfaitement valide.
-Moxie Marlinspike a montré qu'un certificat non-CA peut signer un certificat. Certains navigateurs accepteront cette signature comme valide! Le programme sslsniff fait beaucoup plus de choses que signer des certificats, mais il s'appuye sur cette méthode.
-L'IDN permet de substituer une URL à une autre. Ainsi, l'URL www.mabanque.com/variable=2&tot=3@evil.com peut être lue comme étant l'utilisateur "www.mabanque.com/variable=2&tot=3" se connectant sur evil.com. Bien entendu la barre oblique est un caractère exotique et non pas le /. Le site evil.com possède un certificat valide. sslstrip utilise ce moyen pour rediriger de manière transparente un utilisateur d'un site légal vers un autre.
-Le Nul prefix certificate permet de se faire passer pour un autre site lors de la vérification du CN de ce site par le navigateur.

Ces failles ne sont pas toutes techniquement corrigeable. Il semble en effet particulièrement difficile d'empêcher le phishing et la naïveté des gens cliquant dessus.

Toutefois, la majorité de ces attaques peuvent être évitées via un minimum de vigilance de la part de l'utilisateur: vérifie-t'il les certificats qui lui sont présentés?

En conclusion, je dirais que le SSL/TLS est fiable, et ferai confiance aux protocoles s'appuyant dessus, tant que l'utilisateur et l'administrateur du site sont vigilants.