SSL
Le protocole SSL (Secured Socket Layer) a été conçu par Netscape pour assurer une communication confidentielle et fiable entre deux applications (un client et un serveur), pour identifier le serveur et parfois le client. SSL nécessite un protocole de transport sûr (par exemple TCP) pour la transmission et la réception de données.

Le protocole SSL permet la sécurisation de tout protocole applicatif s'appuyant sur TCP tels que HTTP, LDAP, NNTP, SMTP, FTP ou Telnet. Dans la pratique, les implémentations éprouvées de SSL s'appliquent surtout à HTTP (HTTPs) et LDAP (LDAPs). SSL est directement implémenté dans le code du navigateur (Internet Explorer ou Netscape Communicator) et dans le code des serveurs HTTP (Iplanet, IIS, Apache).

Le protocole est composé de deux couches. Au niveau le plus bas, juste au dessus d'un protocole de transport sûr, se trouve le SSL Record Protocol qui permet de transmettre de manière cryptée les données. Celui-ci est utilisé pour encapsuler d'autres protocoles de plus haut niveau tel que le SSL Handshake Protocol qui permet au serveur et au client de s'authentifier sur le principe de cryptographie des clés asymétriques (clé publique/clé privée) et symétriques avant d'échanger des informations.

Le protocole Handshake SSL est utilisé pour négocier les attributs d'une session. Les messages constituant le protocole Handshake SSL doivent être présentés dans un ordre bien précis; dans le cas contraire, il en résulte une erreur fatale.

Phase 1: Etablissement des paramètres de sécurité
Cette phase a pour but d'établir le lien sécurisé. Le client envoie au serveur un message client_hello contenant des paramètres tels que, sa version de SSL utilisée, son identifiant de connexion, une liste d'algorithmes d'échange de clés et de chiffrement supportée par le client et classée selon la qualité de l'algorithme. Il envoie aussi un jeu de données qui sont générées aléatoirement. Après avoir envoyé ces requêtes, le client attend la réponse du serveur.

Phase 2: Authentification du serveur et échange des clés
Le serveur envoie server_hello, qui contiendra la version de SSL, les meilleurs algorithmes à utiliser, un jeu de données générées aléatoirement et le certificat s'il existe . Dans le cas où le serveur n'a pas de certificat, ce premier message sera suivi d'un message server_key_exchange pour qu'il puisse tout de même transmettre sa clé publique. Ensuite, le serveur peut demander au client un certificat en envoyant un message certificate_request (cas de PKI Public Key Interface). Finalement, le serveur envoie le message server_done, qui signifie la fin de cette phase et que le serveur se met en attente.

Phase 3: Authentification du client et échange des clés
Le client doit vérifier que le certificat envoyé par le serveur est valide, et que les autres paramètres sont corrects. Si le serveur a demandé au client d'envoyer un certificat, le client envoie un message certificate contenant le certificat (s'il n'a pas de certificat, il envoie un message no_certificate).
Il génère ensuite à partir de l'algorithme de chiffrement choisi une "pré" clé secrète (PRE_MASTER_KEY). Il envoie ensuite un message client_key_exchange contenant la "pré" clé secrète cryptée à l'aide de la clé publique du serveur. Pour finir cette phase, le client envoie un message certificate_verify. pour indiquer que le certificat du serveur a été vérifié

Phase 4: Fin
Le serveur vérifie éventuellement la validité du certificat du client. Il déchiffre ensuite la "pré" clé secrète à l'aide de sa clé privée. Le client et le serveur réalisent une même série d'opérations pour obtenir des clés secrètes de session à partir de la "pré" clé secrète et des données aléatoires échangées précédemment.
Le client envoie enfin le message finished, qui authentifie le client et valide l'échange de clés. Le serveur répond en envoyant son message finished. Les deux parties sont maintenant identifiées, le protocole handshake est terminé et les communications sécurisées (chiffrées avec la clé secrète générée) peuvent avoir lieu.

Remarque : à tout moment, si une des deux parties ne peut être identifiée la connexion ne peut pas être établie.

Avantages : très simple, très bien connu, très répandu (système majoritaire) , bon marché, module de cryptage intégré aux navigateurs
Inconvénients : pas de sécurité absolue, refus d'une commande par le client (car rien n'indique que c'est lui qui a passé la commande), réticence psychologique du grand public (en France en particulier), le client prend le risque de donner son n° de carte à un site pirate (non autorisé).