JDNet | Solutions | Emploi | Votre high-tech
 
Linternaute | Copainsdavant
Séminaires & Evénements | Etudes
   

Rechercher  

 
Sociétés Prestataires Carnet Formations Progiciels Encyclo Fonds Guide d'achat Comparateur Téléchargement Livres
Actualités
   2003
   2002
   2001
   Livres
Rubriques
   Java/J2EE
   PHP
   XML
   Client Web
   Technos .NET
   Flash
   Algo/Méthodes
   Outils

Dossiers
   Tous les dossiers

   PHP, Flash, SVG
   Perl / CGI - SSI
   Langages Web
   Services Web
   Sécurité
Ressources
   Interviews

   Téléchargement
   Composants
   Documentation
Contacts
   Rédaction
   Webmaster
© Benchmark Group


Les principes du Secure Socket Layer (troisième partie)
Troisième volet sur l'encodage SSL : vulnérabilités du protocole.

Après l'encodage et l'authentification SSL, voyons maintenant à quelles sortes d'attaques le protocole peut être exposé. Théoriquement, SSL est vulnérable aux attaques par force brute (tentatives de déchiffrement direct d'un message crypté) si les clefs utilisées sont de 40 bits. C'est pourquoi, comme nous l'avons vu dans notre article précédent, il est plus sûr d'utiliser des clefs de 128 bits pour se prémunir des attaques.
Les caractéristiques temporelles et financières de ce type d'attaque sont facilement calculables. Des renseignements sur le type de SSL utilisé indiquent le matériel et le temps nécessaires à l'attaque. Le chiffrement à 40 bits est de moins en moins cher et long à attaquer, même pour un pirate seul.
Tant qu'il n'existe pas d'algorithmes cryptographiques capables d'attaquer directement le chifrfrement 128 bits, ce dernier pourra être considéré comme sûr.

Homme au milieu
L'attaque la plus classique est celle de "l'homme au milieu". A l'aide d'un programme interceptant la communication SSL entre un client et un serveur, un troisième communicant va intervenir. Il va se substituer au serveur vis à vis du client. Si la totalité de la procédure de l'authentification est suivie, cette attaque doit échouer. En effet, au début de la procédure, le client doit identifier le serveur. Pour ce faire, il lui demande un certificat. Le client vérifie le certificat en regardant la signature et en vérifiant si le nom du donneur de certificat est reconnu.
A ce moment, même si l'homme au milieu essaie de jouer le rôle du serveur, il est bloqué. S'il fournit un faux certificat, la vérification de la signature le détectera. Si la signature est une signature légitime pour lui, mais pas pour le serveur, c'est grâce à la vérification du nom du serveur que l'attaque sera détectée.
Il est possible que ce troisième homme arrive à fournir un certificat légitime pour le serveur qu'il cherche à remplacer. Cependant, il ne possède pas la clef privée du serveur, il ne pourra donc pas encoder convenablement la réponse.
Admettons finalement que le malfrat, en plus de fournir le certificat légitime, possède la clef privée. Il sera malgré tout dans l'impossibilité de déchiffrer la clef de session.

Texte clair
Dans un autre genre, l'attaque à "texte clair" est possible lorsque l'attaquant possède les textes chiffrés de plusieurs messages, ainsi que les textes clairs leur correspondant. Il va chercher à retrouver la ou les clefs utilisées pour chiffrer, ou un algorithme permettant de déchiffrer d'autres messages chiffrés avec ces mêmes clefs.
Dans ce type d'attaque, on distingue les attaques à texte clair connu des attaques à texte clair choisi. Dans le deuxième type, l'attaquant a non seulement accès aux textes clairs et chiffrés, mais en plus il peut crypter lui-même les messages, même s'il ne connaît pas la clef.
SSL peut être vulnérable à cette attaque. Le seul moyen de s'en prémunir est d'utiliser des clefs de session très grandes. Par exemple, le client génère une clef très grande. Il en envoie une partie au serveur en clair, l'autre en cryptée. Le serveur combinera les deux portions pour retrouver la clef de session d'origine.

Replay
Le SSL peut être sujet à un troisième type d'attaque : l'attaque replay. Si l'attaquant enregistre une session de communication entre un client et un serveur, il pourra se reconnecter plus tard à ce même serveur pour le faire ré-emmettre les messages envoyés par le client.
SSL se protège de cette attaque grâce à l'utilisation d'une nonce. Il s'agit d'une carte d'identité de la connexion. Elle est différente à chaque fois. En théorie, il est impossible de la prévoir car elle est basée sur une série d'évènements aléatoires.
Un attaquant possédant du matériel de bonne qualité pourrait éventuellement enregistrer plusieurs sessions entre le client et le serveur, et tenter de choisir la bonne en se basant sur la nonce que le serveur envoie dans son message SERVER-HELLO. Mais, les nonces ayant une longueur de 128 bits, il lui faut 264 nonces pour obtenir 50% de chances de choisir la bonne session.

SSL n'est pas inattaquable, loin de là, mais premièrement, il est nécessaire de suivre la procédure dans les moindres détails, surtout au niveau de l'identification des deux parties, quelles qu'elles soient; deuxièmement, choisir le chiffrement le plus important possible (128 bits, par exemple) décourage les attaques, compte tenu du temps et de l'argent nécessaires à l'attaque.

[Serge Descombes 5 septembre 2002 , JDNet]

 
Gratuit - Les nouveautés de
JDNet Développeurs
Toutes nos newsletters
 

Quel est le meilleur langage pour aborder la programmation ?
Basic (VB & co...)
C/C++
Java/C#
PHP
Pascal/Delphi
Perl
Python
autre...



Les outils de développement dans le Guide des Solutions
e-business

L'encyclopédie JDNet Toutes les notions pratiques, techniques et économiques relatives à l'e-business.
>> Accès à la rubrique "Développement"

Comparez les prix Matériel, PDA, modems...
Les bonnes affaires de la high-tech avec Kelkoo.
>> Comparateur

Société | Contacts | Publicité | Presse | Recrutement | Tous nos sites | Données personelles
Pour tout problème de consultations, écrivez au Webmaster.
© Benchmark Group, 4 rue diderot 92156 Suresnes Cedex