URL: https://linuxfr.org/users/tifauv/journaux/attaque-contre-ssltls Title: Attaque contre SSL/TLS Authors: Olivier Serve Date: 2009年11月05日T23:02:36+01:00 Tags: ssl et cybersécurité Score: 50 Un post est paru aujourd'hui sur ./ à propos d'une attaque du type « homme du milieu » sur SSL (Secure Socket Layer). Cela fait suite à un message sur la liste de diffusion TLS (Transport Layer Security, nom 'officiel' du SSL v3) de l'IETF (Internet Engineering Task Force, organisme de normalisation international). **SSL/TLS, quèsaco ?** SSL est un protocole de sécurisation des échanges réseaux initialement créé par Netscape. Il est notamment utilisé pour les connexions HTTPS (paiement en ligne par exemple). SSL permet l'authentification des participants et le chiffrement des données. Il existe deux modes de SSL : serveur ou client. En SSL serveur, seul le serveur possède un bi-clé (couple clé publique/clé privée qui identifie une entité). Autrement dit, le client peut authentifier le serveur, mais le serveur ne sait pas qui est le client. C'est le mode utilisé pour le paiement en ligne. Le serveur n'a pas besoin de savoir qui vous êtes, mais vous avez besoin de savoir que le serveur est bien qui il prétend être. En SSL client, le client possède aussi son bi-clé, ce qui permet au serveur de l'authentifier. C'est une authentification mutuelle (utilisée pour la déclaration des impôts en France par exemple). **Bon, et l'homme du milieu alors ?** C'est un type d'attaque qui consiste à se placer entre un client et un serveur et à se faire passer pour l'un afin d'abuser l'autre. Dans notre cas, il s'agit d'abuser le serveur. **Mais SSL n'est pas protégé contre ça ?** Si. Mais une « faille » a été découverte. Pour faire simple, une communication SSL débute par une négociation durant laquelle le client et le serveur se font coucou et se demandent comment ça va s'échangent des infos (algorithmes de chiffrement connus, certificats, calcul de la clé de session...). Bref, ils se mettent d'accord pour la suite. Un fois que cet échange est fini correctement des deux côtés, le client peut envoyer ses données qui seront automatiquement chiffrées. Jusque là, ça va. Seulement parfois, le serveur doit demander une renégociation. C'est le cas par exemple quand on veut passer d'une connexion SSL serveur en SSL client. Ou quand le client propose des algorithmes de sécurité trop faibles pour le serveur. Là encore, c'est prévu par le protocole, pas de souci. **Et alors, cette faille ?** J'y arrive. Prenons l'exemple d'un serveur web tout ce qu'il y a de plus classique. Aline Nehat reçoit un courriel de sa banque lui demandant de vérifier qu'elle accède bien à son compte en ligne. Le courriel est bien fait, il y a même un lien direct vers le site de la banque ! Aline clique donc dessus et arrive sur le site de sa banque. Comme d'habitude, elle demande à s'authentifier. Comme vous l'avez deviné, notre chère Aline est victime d'un phishing. Elle n'est pas réellement sur le site de sa banque mais sur une contrefaçon parfaite, qui se place ainsi en « homme du milieu ». Cet intrus met la requête d'Aline en attente et démarre une session SSL serveur sur le véritable site de la banque. Cependant, il met deux (ou plus) requêtes HTTP dans les données (c'est parfaitement faisable en HTTP 1.1 avec du keepalive). La première demande une page requérant une authentification client, donc une renégociation SSL. Le serveur démarre alors une renégociation SSL, sur _la même connexion_. À partir de là, l'intrus envoie la requête initiale d'Aline (qu'il avait mise de côté) au serveur et se content de relayer les messages entre les deux. Ça y est, l'attaque a eu lieu. Vous ne l'avez pas vue passer ? Aline et le vrai serveur non plus. **Et moi non plus, elle est où l'attaque ?** Regardons la scène au ralenti du point de vue du « vrai » serveur : 1. Il voit une demande de connexion sur son port SSL. La requête vient de l'intrus, mais il n'y a rien de suspicieux ici, donc il négocie et ouvre le canal SSL. 1. Il reçoit une suite de requêtes HTTP (de l'intrus) qu'il commence à analyser. La première demande une page pour laquelle il faut du SSL client. Pas de problème, il met les requêtes de côté et lance une renégociation 1. L'authentification se passe bien, il reprend donc les données qu'il a mises au chaud et exécute les requêtes. Vous voyez le truc ? Toujours pas ? Relisez les 3 étapes précédentes. Lentement. Laissez-les infuser en vous. Vous ne voyez vraiment pas ? Bon, d'accord, parce que je suis gentil : _Le serveur vient d'exécuter des requêtes forgées par l'intrus sur une connexion authentifiée avec Aline._ Tout vient du fait que le serveur met en attente la requête initiale qui déclenche la renégociation, puis l'exécute une fois la renégociation effectuée. Seulement, la requête initiale n'est pas couverte par l'authentification client, puisqu'elle est reçue avant. Pourquoi le serveur fait-il comme ça ? Parce qu'il n'a pas le choix. Il ne peut pas demander au client de réémettre la requête une fois la renégo validée. Il n'y a pas de code HTTP pour ça. Le serveur est donc bien obligé de réutiliser la requête initiale. Ce problème est identifié depuis Août, et les découvreurs ont dès lors commencé à analyser les implications et corrections possibles. Un premier patch pour OpenSSL existe : il désactive toute renégociation. C'est brutal, mais c'est le seul moyen efficace pour le moment. Notes : 1. Je n'ai pris l'exemple du phishing qu'afin de scénariser l'histoire. On pourrait imaginer d'autres moyen pour qu'Aline aille sur l'intrus (DNS spoofing par exemple) 1. Bien que je n'aie présenté qu'un exemple avec un serveur HTTP, le principe reste valide avec d'autres protocoles. Sources : 1. [Message sur la ML de l'IETF](http://www.ietf.org/mail-archive/web/tls/current/msg03928.html) 1. [Message sur Slashdot](http://it.slashdot.org/story/09/11/05/144252/Man-In-the-Middle-Vulnerability-For-SSL-and-TLS) 1. [Site avec des explications](http://extendedsubset.com/?p=8) d'un co-découvreur (indépendamment de l'IETF) 1. [Patch OpenSSL](http://www.links.org/files/no-renegotiation-2.patch)