Si vous avez lu attentivement jusqu'ici, c'est bon, vous avez tout pour comprendre le HTTPS.
Rien d'original en effet, du hash, du chiffrement symétrique et du chiffrement asymétrique.
Ainsi, une fois que le client et le serveur sont d'accord sur les algorithmes à utiliser, le serveur génère la clé publique et privée du chiffrement asymétrique, envoie la clé publique (en pratique, il s'agit plutôt de certificat) au client et garde la clé privée. Le client génère une clé pour le chiffrement symétrique, la chiffre avec la clé publique du serveur. Le tout est envoyé au serveur qui déchiffre avec sa clé privée.
Ce mécanisme permet ainsi de transmettre la clé privée d'un chiffrement symétrique de manière sécurisée.

Le HTTPS est en fait une utilisation du HTTP classique, sécurisé par SSL (Secure Socket Layer) inventé par Netscape.
Le SSL se place dans le modèle TCP au niveau de la couche session, sous la couche application.
Ceci est primordial car cela signifie que toute application peut utiliser SSL.

Voyons rapidement le mode de fonctionnement.
Lorsqu'on appelle un page en HTTPS, la première étape consiste pour le client et le serveur à se mettre d'accord sur les méthodes de chiffrement.
Pour se rendre compte de cet échange, on va utiliser Ethereal dont voici quelques captures.

On voit dans la liste des informations envoyées par le client la liste des méthodes de chiffrement qu'il connaît :

Le serveur va à son tour envoyer un "server Hello" avec plusieurs informations :

Dans les informations qu'envoie le serveur, on trouve la méthode de chiffrement qu'il choisit, ainsi que son certificat (voir chapitre suivant).

Enfin, la troisième phase, le client va générer la clé privée de chiffrement symétrique, la crypter grâce à la clé publique du serveur et l'envoyer au serveur.

La transmission de données chiffrées grâce à cette clé peut maintenant commencer.

Pour utiliser le SSL sous windows, vous trouverez toutes les informations nécessaires en suivant [ ce lien ].
Pour linux, le mieux est de se renseigner auprès de la documentation de sa propre distribution, un package est bien souvent disponible.

Je viens de vous présenter le principe du HTTPS et ça a l'air incrackable.
Et bien tel que je viens de le présenter, ça ne vaut rien, car n'oublions pas que depuis le début de cet article, un homme est entre nous et le serveur.
Imaginez que cet homme vous envoie lui-même sa clé publique au bon moment et possède sa clé privée pour déchiffrer. Il sera capable de lire tout ce que vous écrivez comme s'il n'y avait aucun chiffrement.
L'important pour le hacker sera de faire croire au visiteur qu'il est bien connecté au bon site et non au hacker. Pour cela, il existe plusieurs techniques, on peut par exemple pirater le site ciblé et y mettre une redirection automatique vers le site du hacker qui sera un clone du site original. Pour résoudre ceci, il faut utiliser un certificat, qui consiste pour un serveur à enregistrer sa clé publique auprès d'un organisme externe qui ainsi certifie sa validité.
Le serveur n'envoie plus sa clé publique, mais le certificat entier que le client valide auprès de l'organisme correspondant.

En cliquant sur le petit cadenas en bas à droite de Firefox, vous pourrez ainsi voir ceci :