• 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.

Le protocole ChangeCipherSpec (CCS)

Ce protocole comprend un seul et unique message (1 octet) qui porte le même nom
que le protocole, il permet d'indiquer au protocole Record la mise en place des algorithmes
de chiffrement qui viennent d'être négociés.

Le Protocole SSLRecord

Ce protocole intervient après l'émission du message ChangeCipherSpec.il permet
de garantir :
- la confidentialité à l'aide de chiffrement des données
- l'intégrité à l'aide de génération d'un condensât.


Le protocole SSL Alert

Ce protocole génère des messages d'alerte suite aux erreurs que peuvent s'envoyer
le client et le serveur. Les messages sont composés de 20 octets, le premier étant soit fatal soit warning. Si le niveau de criticité du message est fatal, la connexion SSL est abandonnée. Le deuxième octet est utilisé pour le code d'erreur.

Liste des Messages du protocol Alert:

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

• 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?)

SSL_NULL_WITH_NULL_NULL

SSL_RSA_WITH_DES_CBC_MD5

• 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") .

• 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.