Aujourd'hui je vous propose de découvrir le SSL. En prévision de futures vidéos qui concerneront la mise en place du HTTPS sur nginx et sur Apache je pense qu'il est important de faire un point sur ce protocole afin de mieux comprendre ce que l'on devra ensuite configurer sur notre serveur.
SSL ou TLS ?
Avant de commencer, une petite aparté sur la différence entre SSL et TLS. SSL, pour Secure Sockets Layer, est le nom du protocole lorsqu'il appartenait à Netscape. Après la version 3.0, l'IETF (Internet Engineering Task Force) décide de prendre le relais pour rendre le protocole plus ouvert et plus standardisé. Suite à des discussions avec Netscape et Microsoft et pour éviter des problèmes de droits, ils renomment le protocole TLS 1.0. Même si aujourd'hui on continue de parler du "SSL" on parlera en réalité du protocole TLS (le SSL n'étant plus maintenu depuis 2001). C'est foireux, mais c'est comme ça...
Pourquoi le SSL ?
Avant de commencer, il est important de faire le point sur l'état actuel des choses pour comprendre pourquoi on a besoin de cette couche de sécurité supplémentaire. Le problème aujourd'hui est que les données circulent en clair lors des échanges entre les machines. Ainsi, quelqu'un qui est capable de se placer entre vous et le serveur pourra intercepter et lire les informations que vous envoyez.
De la même façon, nous n'avons aucune garantie sur l'identité du serveur avec lequel on communique. Ainsi, si quelqu'un modifie les DNS, lorsque l'on tapera le nom de domaine auquel on souhaite accéder on sera dirigé vers un faux serveur qui interceptera les informations que l'on va soumettre.
L'enjeu du SSL est double :
- Permettre de chiffrer les informations afin de s'assurer que personne ne puisse intercepter les échanges entre nous et le serveur.
- Vérifier l'identité du serveur avec lequel on communique afin de s'assurer qu'il correspond bien au nom de domaine demandé.
Chiffrer les informations
Le premier objectif du SSL est de permettre le chiffrage des informations entre les deux machines. Pour cela, le client va commencer par envoyer une liste des éléments qu'il supporte :
- Le type de clé à utiliser pour chiffrer les informations
- L'algorithme de chiffrage à utiliser
- Le type de Hash à utiliser pour vérifier l'intégrité des messages
Une fois ces informations transmises, le serveur va sélectionner les éléments à utiliser en fonction d'une liste de préférence. Une fois cette sélection faite il va renvoyer son choix au client et va aussi transmettre sa clé publique (clé qui permettra au client de chiffrer toutes les informations qu'ils souhaitent communiquer avec le serveur). Le client va alors pouvoir générer une clé pre-master Secret qui permettra de générer une clé symétrique qui sera utilisée pour les futurs échanges. Cette pre-master Secret est alors chiffrée avec la clé publique du serveur et est transmise à ce dernier. Le serveur reçoit alors la pre-master Secret chiffré, et la déchiffre à l'aide de sa clé privée. Enfin le serveur et le client génèrent une clé symétrique à partir de la pre-master Secret (cet échange de clé peut varier suivant l'algorithme de chiffrage choisi au début de la connexion).
Une fois en possession de cette clé symétrique le serveur et le client vont pouvoir communiquer de manière sécurisée. Cette clé pourra être utilisée à la fois pour le chiffrage, mais aussi le déchiffrage des informations qui seront transmises.
Les Certificats
Le problème avec l'étape précédente, c'est que l'on n'a aucune garantie sur l'identité du serveur avec lequel on communique. N'importe qui peut générer un couple clé public / clé privé et commencer à chiffrer les informations avec le client. Il faut donc un moyen de s'assurer que le serveur est bien celui qui correspond au nom de domaine.
Pour cela on utilisera un système de certificats. Les certificats peuvent être assimilés à des cartes d'identité virtuelles. Comme dans la réalité ces cartes d'identité, une fois vérifiées, permettent de s'assurer que la personne que l'on a en face de nous est bien la bonne. Les certificats seront ainsi utilisés pour signer les clés publiques.
Pour obtenir un certificat pour notre serveur, il faudra passer par une autorité de certification à qui on enverra différentes informations nous concernant ainsi que la clé publique du serveur. Cette autorité se chargera de vérifier que les informations soumises sont exactes. Une fois ces informations vérifiées l'autorité de certification va utiliser sa clé privée pour signer les informations que l'on a soumises et générera ainsi un certificat qui nous sera transmis.
Comme pour notre serveur, cette autorité de certification peut elle-même disposer d'un certificat généré par une plus haute autorité : L'autorité de certification racine. Dans ce cas-là, ce certificat intermédiaire (appartenant à l'autorité de certification) nous sera aussi transmis. Ainsi nous nous retrouvons donc avec un certificat signant notre clé publique, mais aussi un certificat intermédiaire signant la clé publique de notre autorité de certificat.
Lorsque le client va contacter le serveur, plutôt que de lui envoyer directement sa clé publique, le serveur lui transmettra le certificat (qui contient nos informations, notre clé publique, ainsi que la signature) et aussi les différents certificats intermédiaires. Le navigateur est équipé par défaut des clés publiques des différentes autorités de certification racine. Il pourra alors utiliser ces clés publiques pour vérifier la signature du certificat intermédiaire. Si la signature est correcte, cela veut dire qu'il peut faire confiance à ce certificat intermédiaire et du coup utiliser la clé publique de ce certificat intermédiaire pour vérifier le certificat du serveur. C'est ce que l'on appelle la chaîne de confiance, où tous les maillons de la chaîne doivent être "de confiance" pour que le système fonctionne. Si le certificat est jugé de confiance, qu'il correspond au nom de domaine demandé et qu'il n'est pas expiré alors le navigateur va envoyer une demande OCSP à une autorité de validation pour vérifier que le certificat du serveur n'a pas été révoqué.
Résumé
Pour résumer, lorsque l'on se connecte à un site Web qui utilise le TLS différentes étapes sont mises en place avant le premier échange de données :
- Le client informe le serveur qu'il souhaite utiliser le protocole SSL ou TLS et indique quelle version du protocole il va utiliser ainsi que les systèmes de chiffrement qu'il supporte
- Le serveur envoie au client son certificat, qui contient sa clé publique, et indique au client quel système de chiffrement il a choisi parmi les choix proposés.
- Le client tente alors de déchiffrer la signature numérique du certificat (ou du certificat intermédiaire) à l'aide des clés publiques des autorités de certifications intégrées par défaut dans le navigateur.
- Si le certificat intermédiaire est jugé de confiance, on utilise sa clé publique pour vérifier le certificat du serveur.
- Si la signature du certificat intermédiaire, ou du certificat du serveur n'est pas déchiffrable alors le navigateur affichera une alerte comme quoi le certificat n'est pas valable et l'utilisateur peut choisir de continuer à communiquer avec ce serveur malgré tout ou de s'arrêter là.
- Le client génère alors une clé pemaster secret et la chiffre avec la clé publique reçue à l'étape 2. Il envoie alors cette clé chiffrée au serveur et utilise le pre-master secret pour générer la clé de session symétrique.
- Le serveur déchiffre le pre-master secret à l'aide de sa clé privée et l'utilise aussi pour générer la clé de session symétrique
- Le serveur et le client disposent alors maintenant qu'une clé symétrique qui permettra de chiffrer les futurs échanges.
- Une fois la connexion terminée (après un temps d'inactivité prédéfinie ou par l'envoi d'un signal de déconnexion) le serveur va révoquer la clé de session. Et il faudra alors repasser par toutes les étapes précédentes pour entamer une nouvelle connexion.
