SSL nécessite-t-il un certificat côté client?
Un ami insiste pour dire que le navigateur et le serveur ont tous deux besoin de certificats. Je dis non, seul le serveur en nécessite une, avec deux clés. La question est de savoir si le navigateur utilise une sorte de certificat (pas seulement une clé) pour le chiffrement dans les communications SSL/TLS avec le serveur.
Votre ami est correct Le navigateur doit disposer du certificat de l'autorité de certification racine, afin de pouvoir vérifier que le certificat du serveur a été signé par une autorité de certification légitime.
Le cas typique des certificats émis par une partie de confiance (Let's Encrypt, etc.)
Les certificats de serveur sont essentiels car le client doit vérifier qu'il parle avec le serveur attendu afin de détecter les attaques d'intermédiaire. Pour s'authentifier auprès d'un client, le serveur a besoin pour cela du certificat lui-même, qui est public, et de la clé privée correspondant au certificat uniquement connu du serveur. Pour accepter un certificat fourni par le serveur comme approuvé, le client vérifie ensuite, entre autres choses, si ce certificat a été émis par une partie de confiance, c’est-à-dire une autorité de certification approuvée (CA signifiant autorité de certification, c’est-à-dire l’entité qui délivre les certificats). Ces autorités de certification approuvées sont stockées en tant que certificats dans le magasin de données de confiance du système d'exploitation ou du navigateur du client. Ce sont les types de certificats nécessaires du côté client.
Et puis, il existe des certificats clients utilisés pour authentifier le client auprès du serveur. Celles-ci sont facultatives et utilisées que rarement. Si ceux-ci sont utilisés, le client a non seulement besoin du certificat (public) lui-même, mais également de la clé privée secrète correspondante, similaire à celle dont le serveur a besoin pour s'authentifier auprès du client.
Le cas rare des certificats de serveur auto-signés
Dans ce cas, le serveur envoie un certificat qui n'est pas émis par une autorité de certification connue du navigateur (ou de l'application ou d'un autre client). Dans ce cas, aucun certificat n'est impliqué côté client, mais le client doit trouver un autre moyen de vérifier si le certificat est celui attendu. En règle générale, le navigateur demande à l'utilisateur d'ajouter une exception dans ce cas.
Le cas encore plus rare d'absence de certificat
SSL/TLS peut également être utilisé sans aucun certificat, c’est-à-dire même pas côté serveur. Dans ce cas, l'authentification est effectuée avec d'autres méthodes, comme une clé secrète pré-partagée entre le client et le serveur (PSK). Ces méthodes sont rarement utilisées et les navigateurs ne les prennent pas en charge.
Regardons ce qui se passe entre le serveur et le client avec SSL. De Wikipedia :
[N] ous négociez une connexion avec état en utilisant une procédure de prise de contact. [...] Au cours de cette négociation, le client et le serveur s'accordent sur différents paramètres permettant d'établir la sécurité de la connexion:
- La prise de contact commence lorsqu'un client se connecte à un serveur prenant en charge TLS demandant une connexion sécurisée et qu'il présente une liste des suites de chiffrement prises en charge (fonctions de chiffrement et de hachage).
- Dans cette liste, le serveur choisit une fonction de chiffrement et de hachage qu'il prend également en charge et informe le client de la décision.
- Le serveur renvoie alors généralement son identification sous la forme d'un certificat numérique. Le certificat contient le nom du serveur, l'autorité de certification approuvée qui certifie l'authenticité du certificat et la clé de cryptage publique du serveur.
- Le client confirme la validité du certificat avant de continuer.
- Pour générer les clés de session utilisées pour la connexion sécurisée, le client:
- chiffre un nombre aléatoire avec la clé publique du serveur et envoie le résultat au serveur (que seul le serveur devrait pouvoir déchiffrer avec sa clé privée); les deux parties utilisent ensuite le nombre aléatoire pour générer une clé de session unique pour le cryptage et le décryptage ultérieurs des données au cours de la session
- utilise l'échange de clé Diffie-Hellman pour générer de manière sécurisée une clé de session aléatoire et unique pour le chiffrement et le déchiffrement, qui possède la propriété supplémentaire de transfert de confidentialité: si la clé privée du serveur est divulguée à l'avenir, elle ne peut pas être utilisée pour déchiffrer la session en cours, même si la session est interceptée et enregistrée par un tiers.
Ceci conclut la négociation et commence la connexion sécurisée, qui est chiffrée et déchiffrée avec la clé de session jusqu'à la fermeture de la connexion.
À aucun moment le serveur ne demande un certificat au client. En règle générale, à l'étape 4 (confirmation de la validité du certificat), le client utilise un magasin local de certificats d'autorité de certification pour vérifier que la chaîne de certificats présentée par le serveur est valide. Cependant, il est tout à fait possible que le client utilise une autre méthode. Par exemple, voici ce qui se passe avec les certificats auto-signés: votre navigateur vous demandera si vous souhaitez accepter ce certificat qui ne peut pas être vérifié, et si vous confirmez, il se fera un plaisir de terminer la poignée de main. Les clients de ligne de commande tels que curl et wget disposent d'options permettant d'indiquer que vous ne souhaitez pas vérifier la chaîne de certificats.
Le client n'a pas besoin de certificats, mais il est recommandé de vérifier l'identité du serveur. Cela signifie que le client a besoin de certificats d'autorité de certification pour vérifier la chaîne de certificats présentée par le serveur.
Il est possible de configurer le serveur pour demander un certificat d'authentification client. Voir cet article MSDN pour une illustration.
TLS peut fonctionner sans certificat "TLS" (c’est vraiment un certificat X.509), ce qui est orthogonal. Un point de terminaison peut avoir un certificat, ou les deux, voire aucun. TLS offre différents avantages, l'authentification n'en est qu'un (mais le plus important en fait, la confidentialité souvent contre-intuitive)