Les principes du Secure Socket
Layer (Première partie)
Ce premier volet concerne l'encodage SSL. Revue et classification des différentes possibilités.
Cet article fait suite au volet introductif
( vocabulaire
et algorithmes de la cryptographie) présentant les bases
nécessaires à la compréhension ce qui va suivre.
Le but est ici la description de l'implémentation la plus
connue des techniques de chiffrement: le protocole SSL (Secure Socket
Layer).
Mis au point pour sécuriser un autre protocole, le fameux TCP/IP,
SSL est utilisé pour chiffrer et authentifier les serveurs. Il entre
dans la catégorie des méthodes de chiffrement à clef publique.
L'objectif est d'assurer une communication confidentielle et fiable
entre un client et un serveur, par exemple, en étant capable de
vérifier l'identité du serveur et/ou du client. SSL nécessite un
protocole de transport, comme TCP, pour la transmission et la réception
des données.
SSL est un protocole qui vient se placer au dessus de la couche
TCP/IP. Il permet aux couches encore supérieures (HTTP, LDAP, IMAP,
SMTP
) de profiter d'un mode d'accès sécurisé. Les trois fonctionnalités
principales de SSL sont :
- l'authentification du serveur,
- l'authentification du client,
- le chiffrement des données.
Il se compose de deux couches : le SSL Record Protocol concerne
l'encodage (envoi des données) et le SSL Handshake protocol
la négociation (phase qui précède la validation des données par
l'un ou par l'autre).
Cette partie est consacré à l'encodage SSL, la négociation faisant
l'objet d'un autre article.
SSL peut prendre en charge différents algorithmes cryptographiques
pour authentifier et envoyer des certificats, et pour établir des
clés. Le sous protocole de négociation a entre autres pour fonction
de définir les paramètres du chiffrement : sera choisi celui qui
répond le mieux aux besoins et aux outils des deux communicants.
Les algorithmes généralement utilisés sont les suivants : DES (Data
Encryption Standard), MD5 (Message Digest), RC2 & RC4 (Rivest encryption
Ciphers), SHA-1 (Secure Hash Algorithm), SKIPJACK (algorithme de
clef symétrique mis en place par Fortezza).
Les algorithmes d'échanges de clef, comme RSA (Rivest, Shamir et
Adleman) et KEA (Key Exchange Algorithm), sont utilisés par la plupart
des chiffrements SSL. Ils déterminent quelle clef symétrique sera
utilisé pour l'échange. SSL 2.0 et 3.0 sont des protocoles supportant
un certain nombre de chiffrements. Pendant la négociation entre
le client et le serveur, ils permettent d'identifier le chiffrement
le plus puissant qu'ils possèdent en commun. Ces chiffrements peuvent
être activés ou désactivés par un administrateur. Les participants
à la négociation choisissent la palette de chiffrements qu'ils vont
mutuellement se proposer. Utiliser tous les chiffrements existants
assure l'universalité de l'échange. A l'inverse, sélectionner uniquement
les chiffrements les plus performants empêche d'être
sollicité pour des échanges à risques.
Nous présentons les différents algorithmes, fonctionnant avec RSA,
du plus sécurisé au moins sécurisé.
- L'algorithme offrant les meilleures garanties est le 3DES
(DES appliqué 3 fois) supportant un chiffrement à 168 bits, couplé
avec SHA-1 pour l'authentification des messages. La taille de la
clef dans ce cas là est si importante qu'il existe un nombre gigantesque
de possibilités de clefs (environ 3.7*10^50). Il est moins rapide
mais plus sûr que RC4. Il est supporté par SSL 2.0 et 3.0.
- Le deuxième algorithme le plus sûr est le RC4 avec
un chiffrement 128 bits, couplé à MD5 pour l'authentification des
messages - lui aussi supporté par SSL 2.0 et 3.0. Le nombre de clefs
possibles est de 3.4*10^38, et RC4 est le plus rapide des modes
de chiffrement.
- Ensuite vient le RC2 avec un chiffrement 128 bits couplé
à MD5 pour l'authentification des messages. Le nombre de clefs possibles
est le même qu'avec le RC4, mais RC2 est plus lent, et cette méthode
n'est supporté que par SSL 2.0.
-Le DES, par ailleurs, permet un chiffrement à 56 bits couplé
avec SHA-1 pour l'authentification des messages. Les 56 bits permettent
une probabilité de 7.2*10^16 clefs différentes. Moins performant
que RC2, il est cependant supporté par SSL 2.0 (avec MD5 à la place
de SHA-1) et 3.0.
- Enfin les deux algorithmes suivants offrent des garanties moindres,
mais restent malgré tout utilisés. Première méthode,
le RC4 avec un chiffrement 40 bits, couplé avec MD5 pour l'authentification
des messages, est supporté par SSL 2.0 et 3.0. Le nombre de clefs
possibles est alors de 1.1*10^12. Seconde méthode, idem sauf que
RC2 est utilisé à la place de RC4. Les caractéristiques sont inchangées,
si ce n'est que RC2 est moins rapide que RC4. La dernière proposition
n'offre que de faibles garanties. L'algorithme n'utilise pas de
modèle de chiffrement, les données ne sont pas protégées. En revanche,
MD5 permet de détecter les attaques et donc de garantir l'intégrité
des données.
D'autres algorithmes sont utilisés avec KEA de Fortezza.
Ils sont supportés par SSL 3.0 uniquement sur les produits Netscape.
Moins nombreux, on en distingue trois différents. Seuls les deux
premiers cités offrent des garanties de sécurités acceptables.
- Le premier est un RC4 avec un chiffrement de 128 bit et couplé
avec SHA-1 pour l'authentification des messages. Il est comparable
au RC4/128 bits/MD5 cité plus haut. C'est l'un des plus forts après
3DES. Il peut générer 3.4*10^38 clefs probables.
- Le deuxième est un RC4 à chiffrement SKIPJACK 80 bits couplé
avec SHA-1 pour l'authentification des messages.
- Le dernier, en parallèle au dernier algorithme RSA présenté précédemment,
n'offre que peu de garanties. Sans systèmes de chiffrement, il utilise
SHA-1 pour l'authentification des messages. Seule l'intégrité des
données est garantie.
Comme indiqué plus haut, cette liste sera complétée
par l'examen de la phase de négociation
SSL.
[Serge Descombes
3 septembre 2002
, JDNet]
|