LINUX:Cryptage SSL
But
Dans cet article, on présente de façon succincte le cryptage SSL. Vous trouverez facilement sur Internet des explications plus complètes et plus précises de ce principe.
Principe
Le but du cryptage SSL est le proposer le cryptage des communications entre deux entités (serveur et client) afin que personne d'autre ne puisse consulter ces communications.
Clé privée et clé publique ou certificat
Ce cryptage est asymétrique. C'est à dire que le maître de ce cryptage est unique et donc ne peut être initié que dans un sens, au contraire d'un cryptage symétrique où les deux partenaires sont sur un pied d'égalité et donc doivent avoir la même clé de cryptage avant toute communication.
La clé privée est créé sur le maître. Cette clé doit être protégée de tout vol. Elle doit impérativement rester sur le maitre^et nul part ailleurs. Elle ne doit jamais être transmise. Dans le cas qui nous occupe, cette clé privée est sur un serveur WEB ou de messagerie.
De son côté, la clé publique ou certificat est créé à partie de la clé privée. Et c'est elle qui sera transmise au client.
Fonctionnement
Un petit dessin vaut mieux qu'un grand discours. J'en ai trouvé un sur le site d'OVH.
Voici les grandes étapes:
- Le client (par exemple le navigateur Firefox d'un PC) demande l'ouverture d'un session auprès d'un serveur WEB (par exemple, le serveur Apache).
- Le serveur envoie sa clé publique au client.
- A ce stade, le client vérifie cette clé par divers mécanismes.
- Le client génère une clé unique de cryptage qu'il crypte sur base de cette clé publique.
- Il l'envoie au serveur.
- Le serveur est le seul qui peux décrypter cette clé unique sur base de sa clé privée que lui seul possède.
- A ce stade, la communication cryptée peut débuter. (Cette clé unique est régulièrement recréé afin de compliquer le piratage éventuel)
Validation du certificat
Le processus décrit ci-dessus est simple et d'apparente à un certificat auto signé, ce qui ne permet pas de vérifier son authenticité auprès d'un organisme reconnu publiquement.
Pour y arriver, on ajoute une couche au principe de base de création des clés privée et publique.
Dans ce cas de figure, ce n'est plus le serveur WEB ou Mail comme ci-dessus qui génère les clés. C'est un organisme reconnu publiquement qui s'en charge. Cet organisme a une clé privée principale. Il est l'Autorité de Certification ou CA. Sur base de cette clé privée, il génère un certificat publique CA. Ce certificat est distribué à tous. On le retrouve dans tous les magasins de certification des machines client. Ainsi, Firefox, Internet Explorer, Thunderbird, MS Outlook,... vont pouvoir s'en servir.
Il va créer une seconde clé privée destinée au serveur WEB ou Mail. Sur base de cette seconde clé privée et de ses propres clés privée et publique CA, il va créer une clé publique ou certificat publique pour notre serveur WEB ou Mail.
Cette autorité devient garante du contenu de la clé (nom de domaine du site WEB ou Mail, localisation, société,...) et elle peut être validée via la clé publique CA. Donc si cette clé publique secondaire est modifiée, elle ne pourra être validée.
Le serveur WEB ou Mail reçoit les clés secondaires privée et publique de ce organisme mais pas la clé privée CA.
Bien sûr, on peut compliquer ce système en créant des CA intermédiaires à un ou deux niveaux qui viennent se placer entre ce CA primaire et la clé du serveur.
Le client (Firefox, Thunderbird,...) quand il reçoit le certificat publique du serveur, il valide sont authenticité sur base du certificat publique CA.
La majorité des organismes CA proposent un service payant mais récemment le service gratuit Let's Encrypt est apparu. Pour pouvoir l'utiliser, il faut que vous possédiez un nom de domaine publique reconnu au niveau du DNS mondial. Il faut aussi que votre serveur aie un service (HTTP) visible à partir d'Internet.