• confidentialité : elle est obtenue par l'utilisation d' algorithmes à chiffrement symétrique>de blocs comme DES, FORTEZZA, IDEA, 3DES ou RC2, ou par des algorithmes à chiffrement symétrique de flots comme RC4 (la longueur des clés peut être limitée suivant les législations propres à l'exportation, et le padding correspondant s'applique aux algorithmes par blocs).
• intégrité : l'intégrité des données est assurée par l'utilisation de MACs (Message Authentication Code) basés sur les fonctions de hachage MD5 (16 octets) ou SHA-1 (20 octets).
• authentification : SSL permet l'authentification des 2 entités (authentification client facultative) basé sur des certificats X.509, et l'authentification des données grâce aux MACs.

• en noir, les échanges initiés par le serveur.
• en rouge, les échanges initiés par le client.
• en jaune, les échanges correspondants à l'authentification du client.

1) Première phase : authentification du serveur
Suite à la requête d'un client, le serveur envoie son certificat au client et lui liste les algorithmes cryptographiques, qu'il souhaite négocier. Le client vérifie la validité du certificat à l'aide de la clé publique du CA (Certificate Authority) contenue dans le navigateur. Si le certificat est valide, le client génère un pré-master secret (PMS) de 48 octets qui servira à dériver le master secret (MS) de même taille, 48 octets, ce qui représente l'entropie maximale de la clé. Ce PMS est chiffré avec la clé publique du serveur puis transmis à ce dernier. Les données échangées par la suite entre le client et le serveur sont chiffrées et authentifiées à l'aide de clés dérivées de la clé maître.

2) Deuxième phase : authentification (optionnelle) du client
Le serveur (et seulement lui) peut demander au client de s'authentifier en lui demandant tout d'abord son certificat. Le client réplique en envoyant ce certificat puis en signant un message avec sa clé privée (ce message contient des informations sur la session et le contenu de tous les échanges précédents).

• L'authentification du client est facultative et au bon vouloir du serveur. Elle est en fait rarement utilisée dans la vie courante (qui possède une paire de clés RSA certifiée?).
• L'authentification du réseau intervient dans tous les cas avant celle du client, ce qui est un gage de sécurité accrue.
• Comme dans IPSec (IKE phase 1), l'authentification reprend les échanges précédents et valide ainsi tout le handshake.
• Notez enfin que seule la clé publique du serveur est utilisée pour faire du chiffrement; celle du client ne sert que pour de la signature.

Les erreurs fatales sont:

• bad_record_mac: réception d'un MAC erroné
• decompression_failure: les données appliquées à la fonction de compression sont invalides
• handshake_failure: impossibilité de négocier les bons paramètres
• illegal_parameter: un paramètre échangé au cours du protocole Handshake ne correspondait pas avec les autres paramètres
• unexpected_message: message non reconnu.

Les warnings sont :

• bad_certificate: le certificat n'est pas bon
• certificate_expired: certificat périmé
• certificat_revoked: certificat révoqué
• certificat_unknown: certificat invalide pour des raisons précisés au dessus
• close_notify: la fin d'une connexion
• no_certificate: réponse négative à une demande de certificat
• unsupported_certificate: le certificat reçu n'est pas reconnu

• SSLeay
• Netscape Entreprise Server
• Apache
• Oracle Web Apllication Server
• Internet Information Server (IIS)
• Lotus Domino d'IBM
• Java Server de Sun Microsystems

Aspects cryptographiques de SSL:

Le handshake SSL permet aux 2 entités de choisir une suite d'algorithmes cryptographiques pour assurer la sécurité de leurs échanges. Cette suite sera de la forme SSL_X_WITH_Y_Z où :

• X désigne l'algorithme utilisé pour l'échange de clés : RSA ou Diffie-Hellman avec signature DSS ou RSA. Notez que DH n'est supporté que par la version 3.0 et non par la 2.0 de SSL. D'autre part, son implémentation n'est pas sensible aux attaques type man-in-the-middle car les paramètres d'exponentiation sont authentifiés par les 2 extrémités.
• Y désigne l'algorithme de chiffrement (voir le paragraphe Pourquoi SSL?)
• Z désigne l'algorithme de hachage (voir le paragraphe Pourquoi SSL?)

La version 3.0 de SSL permet 31 possibilités de suites d'algorithmes cryptographiques différentes. Une de ces possibilités est de ne rien utiliser, ce qui revient à utiliser des algorithmes fictifs ne modifiant pas les données, ce que nous désignons comme suit :

SSL_NULL_WITH_NULL_NULL

Un autre exemple est :

SSL_RSA_WITH_DES_CBC_MD5

Intégrité et authentification


L'intégrité est assurée au moyen de MACs (messages authentication codes), qui ont la double spécificité d'assurer à la fois intégrité et authentification des données. Un MAC allie une fonction de hachage (ici MD5 ou SHA-1, d'où une longueur finale de 16 ou 20 octets) à une clé secrète partagée par les 2 entités. Une façon habituelle de générer des MACs est d'utiliser la fonction HMAC (RFC 2104); ici, SSL définit sa propre fonction pour MACer, mais nous n'entrerons pas dans les détails. Attention, les illustrations font abstraction des headers, qui ne sont pas inclus dans les données protégées.




Confidentialité

Le chiffrement peut-être soit par flots, soit par blocs, suivant l'algorithme choisi. Prenons l'exemple du chiffrement par flot (en gris les données chiffrées):

Après génération du MAC, les données sont directement processées dans la fonction de chiffrement.

Quant au chiffrement par blocs, il est nécessaire de rajouter du padding avant le traitement, pour que la longueur totale des données à traiter soit un multiple de la taille d'un seul bloc (n x 64 bits par exemple).

Evolutions du standard :

La prochaine version du standard aura quelques changements, parmi lesquels on retrouve :

• Support obligatoire de DSA et D-H; RSA devrait également être supporté en facultatif.
• Remplacement de la fonction prorpiétaire de génération de MACs par le standard HMAC (RFC 2104)
• Protection du numéro de version de SSL par les opérations de hachage (pour éviter les attaques par rollback par exemple)
• Nouveau générateur de nombres aléatoires (basé MD5 et SHA-1 à la fois), nouveaux messages d'alerte ("Decryption failed") .

Les attaques et faiblesses de SSL

• SSL est théoriquement vulnérable aux attaques par force brute en cas d'utilisation de clés 40 bits, il est donc conseillé d'utiliser des clés de 128 bits.
• SSL est très vulnérable aux attaques par le milieu (man in the middle): l'attaquant intercepte (physiquement) la requête du client et se fait passer pour le serveur auprès de lui, tout en se faisant passer pour un client auprès du serveur légitime. Il reçoit donc la totalité du flux supposé protégé.
• SSL est faible dans le sens où il n'impose pas l'authentification client (ce serait d'ailleurs difficilement gérable en pratique).
• SSL est faible enfin car il présente des souplesses dans son implémentation, notamment en ce qui concerne la vérification des certificats des serveurs. En effet, le client devrait vérifier la signature, la validité ainsi que le statut de révocation du certificat (au moyen de CRLs ou du protocole OCSP) et devrait s'assurer que le CA concerné appartient bien aux CAs auxquels il fait confiance. Or cela n'est pas obligatoire, et peut permettre à un attaquant de substituer sa propre clé publique à celle du serveur original puis de rediriger le traffic vers son faux site tout en faisant croire au client qu'il communique bien avec son serveur légitime. Il est donc important de bien vérifier les URLs par exemple.
• SSL est éventuellement vulnérable à des attaques plus poussées, basées sur des propriétés cryptographiques. L'utilisation de certificats par exemple nécessite une grande vigilance (date de validité, multitude de CAs inconnus certifiant tout et n'importe quoi... Il suffit de jeter un coup d'oeil à la liste contenue dans votre navigateur pour s'en rendre compte); il existe également des attaques par brute-force sur l'échange de la clé symétrique (2^20 essais) ou des attaques dites de rollback dans lesquelles l'attaquant cherche à modifier le choix des algos d'échanges de clés de façon à ce que les 2 entités n'utilisent pas les mêmes (RSA et DH par exemple). Ainsi, cet attaquant pourra déchiffrer le message car les paramètres fournit par le serveur dans le cas d'un algorithme n'offrent aucune sécurité si on les applique à un autre... Cette attaque peut-être réalisée si une session 3.0 est résumée en session 2.0 par exemple.

Conclusion

Le protocole SSL est actuellement le seul protocole de sécurisation déployé et utilisé à grande échelle, son grand avantage étant sa transparence par rapport au protocole TCP. Il garantit l'authentification, la confidentialité et l'intégrité des données.
Avec son architecture modulaire, il ne se limite pas à des applications traditionnelles, puisque il intègre les réseaux sans fil comme le WAP (Wirless Transport Layer) sous le nom WTLS ( Wireless Transport Layer Security).

Références:

http://www.netscape.com/eng/ssl3/

Mustapha Benjada

SoGoodToBe