V.3.5.2. Architecture
SSL/TLS est conçu pour se servir de TCP afin de fournir
un service sécurisé de bout en bout fiable. SSL/TLS n'est pas un
simple protocole, mais plutôt constitué de deux couches de
protocole.
Record fournit des services de sécurité de base
à divers protocoles de couche supérieure.
La deuxième couche est composée de deux sous
protocoles :
1' Le protocole de poignée de main (Handshake Protocol)
: ce protocole permet d'authentifier les parties en jeu et d'assurer un
mécanisme sécurisé pour la gestion des clés ;
1' Le protocole de changement des spécifications de
chiffrement (Change Cipher Spec protocol, CCS) : ce protocole comprend un seul
et unique message. Son but est d'activer pour la session SSL courante les
algorithmes, les clés et les nombres aléatoires durant la phase
d'initialisation (la phase Handshake). Ceci en passant ces informations au
protocole Record ;
1' Le protocole d'alerte (Alert Protocol) : ce protocole
spécifie les messages d'erreur envoyés entre les clients et les
serveurs. Les messages sont de deux types : le premier contient les messages
d'erreurs fatales (Fatal Error) et le deuxième, les alertes ou les
messages d'erreur non fatale (Warning Error). Si le niveau est fatal, la
connexion est abandonnée. Les autres connexions sur la même
session ne sont pas coupées mais on ne peut pas en établir de
nouvelles.
La Figure V.11 illustre l'Architecture de SSL/TLS.
Fig. V.11. Architecture de SSL/TLS V.3.6.
Protocole Handshake
Le protocole Handshake est la partie la plus complexe
de SSL/TLS. Il permet l'échange des paramètres de
sécurité (nombres aléatoires, liste des algorithmes de
chiffrement, de hachage, etc.) entre le client et le serveur avant que les
données applicatives ne soient transmises. Il permet aussi
l'authentification des
deux communicateurs. Cependant, dans la plupart des cas, le
serveur est uniquement authentifié. Ce protocole peut opérer en
deux formes : soit il établit un échange complet avec la
négociation des paramètres de sécurité (le
Handshake complet), soit il essaye d'utiliser une ancienne session SSL/TLS
déjà négociée (Handshake abrégé).
V.3.6.1. Handshake Complet
La figure V.12 illustre l'échange initial
nécessaire pour établir une connexion complète entre le
client et le serveur.
Le client commence l'échange SSL/TLS en envoyant le
message ClientHello qui contient un nombre aléatoire
(R1), un identificateur de session (S_ID), une liste des
algorithmes de compression (compression_list) et une suite de
chiffrement (cipher_list). Notons que le nombre aléatoire est
une concaténation entre le temps système en format Unix et un
nombre aléatoire.
Le serveur répond en envoyant le message
ServerHello contenant un nombre aléatoire (R2), un
identificateur non nul de session et une suite choisie des algorithmes de
chiffrement et de hachage. Le serveur envoie également un certificat
X.509 contenant sa clé publique pour s'authentifier. Ensuite, le client
vérifie la clé publique du serveur et génère un
nombre aléatoire sur 48 octets connu sous le nom du
pre_master_secret. Le client chiffre le pre_master_secret
avec la clé publique du serveur et l'envoie dans le message
ClientKeyExchange.
A la réception de ces messages, le serveur
déchiffre le pre_master_secret en utilisant sa clé
privée. C'est à ce moment là que le client et le serveur
peuvent calculer un secret partagé, le master_secret, à
partir des nombres aléatoires R1 et R2 et du pre_master_secret.
Ce secret servira par la suite à la dérivation des clés de
chiffrement et de déchiffrement dans les connexions SSL/TLS. Le dernier
échange achève l'instauration d'une connexion sûre. Les
deux entités échangent les messages finished contenant
le hachage de l'ensemble des messages et des paramètres
négociés.
La Figure V.12 illustre l'Handshake SSL/TLS.
Fig. V.12. Handshake SSL/TLS
Si le certificat client est exigé par le serveur (le
serveur envoie le message CertificateRequest), alors le client
répond en envoyant le message CertificateVerify contenant sa
signature sur toutes les informations échangées avec le serveur.
Même si l'authentification par certificat X.509 et par clés RSA
reste la plus utilisée pour l'authentification des serveurs SSL/TLS, ces
derniers peuvent avoir d'autres méthodes d'authentification telles que
l'authentification par des valeurs DH Anonymes (un nombre premier, un
nombre qui lui est relativement premier et la clé publique DH du
serveur), des valeurs DH temporaires (les paramètres DH et une
signature), un échange RSA (où le serveur n'a qu'une
clé RSA pour signer et établir une clé RSA temporaire) ou
finalement par Fortezza (norme de sécurité du
gouvernement américain). Parmi toutes ces méthodes,
l'échange du DH temporaire reste le plus sûr.
| 
