SSL (Secure Socket Layer) et sa variante TLS (Transport Layer Security) sont les deux protocoles les plus utilisées pour sécuriser les échanges sur le réseau Internet. Par exemple, ils sont largement utilisés dans les applications de messagerie, dans les navigateurs Web et dans les logiciels de Voice over IP.
L’augmentation rapide des transactions faites sur Internet a rendu la sécurisation des informations un facteur fondamental. Les sites de commerce électronique, les banques, les gouvernements et beaucoup d’autres entreprises basent leur activité sur la confiance donnée à un protocole de sécurisation. Authentification, intégrité et intimité sont les caractéristiques attendues par les utilisateurs des services et elles sont normalement mises en place avec SSL/TLS. La grande diffusion de ce protocole l’a rendu la cible de nombreuses attaques, qui cherchent d’exploiter les vulnérabilités de ce protocole.
Même si le protocole TLS a été crée pour donner une authentification mutuelle aux applications qui communiquent, dans l’utilisation classique les applications utilisent seulement l’authentification du serveur. Cette procédure est normalement efficace mais pour certaines fonctions n’est pas suffisante : il est aussi nécessaire l’authentification du client. Par exemple, en domaines où la sécurisation des transactions est très importante comme pour un système d’home-banking, le serveur doit avoir confiance de ses utilisateurs.
Si un serveur web a une partie qui est sécurisée avec l’authentification unilatérale et une autre partie qui nécessite d’authentification mutuelle, le serveur ne peut pas savoir a-priori quelles exigences de sécurité seront nécessaires. Dans ce cas là, une phase de renégociation des paramètres de connexion sera nécessaire.
Dans notre projet, nous avons analysé les problématiques relatives à la renégociation des sessions TLS. Ce domaine est en continue évolution et actuellement n’a été pas encore complètement étudié. Plusieurs vulnérabilités ont été découvert et les patches relatives ont été publié, mais les développeurs n’ont pas encore résolu le problème primordiale qui génère toute cette famille d’attaques: HTTPS, qui est composé par la fusion de HTTP et TLS/SSL, est basé sur protocoles de couches différents. La communication des informations entre les deux couches n’est pas prévu par le paradigme ISO/OSI, et pour gérer cette exception ont été introduit des méthodes qui forcement introduisent des vulnérabilités.
L’organisation du document
Le premier chapitre de ce document parlera du protocole TLS, de ses caractéristiques principales et de la procédure d’handshake. Une partie sera dédiée à la renégociation de session et aux problèmes qu’apporte.
Le deuxième chapitre parlera des vulnérabilités du TLS, des attaques du type Man in the Middle et des possibles solutions qui peuvent être mises en place pour résoudre ces vulnérabilités.
Dans le troisième chapitre, après une introduction à l’architecture d’implémentation et de test qui nous avons mise en place sera expliqué comme nous avons pensé et implémenté une attaque au protocole TLS.
Enfin, avec les conclusions, nous chercherons d’évaluer notre travail en un contexte plus grand que quel purement académique.
| Succ. > |
|---|
