Sartomiki.net

OpenSSL
OpenSSL est une implémentation open source des protocoles SSL et TLS. Les librairies qui sont mises à disposition par OpenSSL sont écrites en C et elles permettent de faire tourner facilement les fonctions  de cryptographie principales. OpenSSL est compatible avec la majorité des systèmes d’exploitation présents sur le marché .

OpenSSL permet la création et la gestion des clés privées et publiques, l’assignation des certificats, le cryptage e le décryptage des messages, la création d’une structure client/serveur pour le test des applications qui utilisent SSL/TLS et aussi la gestion des estampilles.

La librairie supporte différents protocoles cryptographiques :
-Algorithmes chiffrement : Blowfish, Camellia, CAST, DES, RC2, RC4, RC5, IDEA, AES
-Fonctions d’hash : MD5, MD2, SHA, MDC-2
-Protocoles à clé publique : RSA, DSA, Diffie-Hellman
-Fonctions d’authentification : HMAC, MD2, MD4, MD5, MDC2, RIPEMD, SHA
-Certificats : X.509

Nous avons utilisées cette librairie pour mettre un place les deux simulations d’attaque qui nous avons réalisée. En fait, on a utilisé OpenSSL pour créer les certificats et la librairie C que OpenSSL met à disposition. Malgré la pénurie de documentation officielle, pour la deuxième solution, on a utilisée des fonctions qui ne sont pas mises à disposition par la librairie, mais que la libraire utilise à l’intérieur.

SSL Proxy 2000
SSL Proxy 2000 est un proxy très simple qui utilise la librairie OpenSSL pour créer des canaux TLS entre un client et un serveur. Il supporte seulement 10 connexions simultanées et le code est très simple et non optimisé. Grace à sa clarté nous avons pu modifier facilement son code pour créer notre simulation d’attaque et comprendre l’utilisation des libraires OpenSSL.

Plateforme de test
Pour nos tests, nous avons crée une infrastructure  basée sur un réseau privé qui connectait trois hôtes : un client, une machine Windows, un serveur et le MITM, des machines Linux. Le client était la seule machine physique présente parce que les deux autres était virtuelles avec le logiciel Vmware Client (pour Windows) et Virtual Box (pour MacOs X).

La topologie prévoyait la connexion des hôtes au même réseau local et l’envoi de tous les messages destinés au serveur au MITM avec une modification du ficher « hosts » du client. Le même résultat peut être obtenu avec du phishing, des attaques DNS ou, à niveau local, avec de l’ARP poisoning.

Le client était un Windows Xp (Service Pack3) qui faisait tourner Mozilla Firefox version 4.0.  Nous avons essayé avec autres systèmes d’exploitation (MacOs X et Ubuntu) mais toujours avec le même browser, parce que la gestion des certificats est très différent pour chaque browser (nous parlons de formats différents et pas complètement compatibles). Néanmoins, nous crayons que la démonstration d’une attaque avec Firefox est significative, en tant qu’il est un des browsers les plus utilisés .

Le serveur était une machine Linux (Debian 6.0) avec Apache web server (version 1.41) et les librairies OpenSSL (version 0.9.8g). Nous avons configuré le serveur pour accepter connexions en claire sur le port 80 et connexions TLS  sur le port standard 443. Le serveur web avait trois zones : la première, la « server root » acceptait les connections en claire seulement pour tester éventuels problèmes. La deuxième, zone « Secure » était accessible avec une connexion TLS avec l’authentification unilatérale du serveur. La troisième, zone « Hypersecure », nécessitait aussi de l’authentification du client avec un certificat.

Le MITM était aussi une machine Linux basée sur Debian 6.0, mais avec des librairies SSL plus nouvelles (version 0.9.8o) et avec notre logiciel installé. La configuration de default de l’application était de écouter les connexions en arrive sur le port 443 et de le rejouer sur le même port du serveur. Avec cette configuration  est possible de limiter au minimum les modifications de paramètres sur le client, avec la seule limitation d’avoir un seul serveur cible.