Clarification SSL bidirectionnelle
Je suis un peu confus quant à la façon dont fonctionne le protocole SSL bidirectionnel. Comment le client crée-t-il son certificat à envoyer au serveur? Est-il généré à partir du serveur et distribué au client?
En outre, quel est l'avantage du protocole SSL bidirectionnel par rapport au protocole SSL unidirectionnel?
Les deux certificats doivent exister avant la connexion. Ils sont généralement créés par les autorités de certification (pas nécessairement les mêmes). (Il existe d'autres cas où la vérification peut être effectuée différemment, mais certaines vérifications le sera doivent être effectuées.)
Le certificat de serveur doit être créé par une autorité de certification approuvée par le client (et conformément aux conventions de dénomination définies dans RFC 6125 ).
Le certificat client doit être créé par une autorité de certification approuvée par le serveur.
C'est à chaque partie de choisir ce à quoi elle fait confiance.
Il existe des outils en ligne d'autorité de certification qui vous permettent de demander un certificat dans votre navigateur et de l'installer là-bas une fois que l'autorité de certification l'a émis. Ils n'ont pas besoin d'être sur le serveur qui demande l'authentification par certificat client.
La distribution des certificats et la gestion de la confiance sont le rôle de l'infrastructure à clé publique (PKI), mise en œuvre via les autorités de certification. Le client et les serveurs SSL/TLS, puis simplement les utilisateurs de cette infrastructure à clé publique.
Lorsque le client se connecte à un serveur qui demande l'authentification par certificat client, le serveur envoie une liste des autorités de certification qu'il accepte d'accepter dans le cadre de la demande de certificat client. Le client peut alors envoyer son certificat client s'il le souhaite et si un certificat approprié est disponible.
Les principaux avantages de l'authentification par certificat client sont les suivants:
- Les informations privées (la clé privée) ne sont jamais envoyées au serveur. Le client ne dévoile pas son secret lors de l'authentification.
- Un serveur qui ne connaît pas d'utilisateur avec ce certificat peut toujours authentifier cet utilisateur, à condition qu'il approuve l'autorité de certification qui a émis le certificat (et que le certificat est valide). Cela ressemble beaucoup à la façon dont les passeports sont utilisés: vous n’avez peut-être jamais rencontré une personne qui vous montrait un passeport, mais parce que vous faites confiance à l’autorité qui délivre le passeport, vous pouvez associer l’identité à la personne.
Vous pouvez être intéressé par Avantages des certificats client pour l'authentification client? (sur Security.SE) .
Ce que vous appelez "SSL bidirectionnel" est généralement appelé TLS/SSL avec authentification par certificat client.
Dans une connexion "normale" à TLS sur example.com, seul le client vérifie qu'il communique bien avec le serveur, par exemple.com. Le serveur ne sait pas qui est le client. Si le serveur veut authentifier le client, la chose habituelle est d'utiliser des mots de passe. Un client doit donc lui envoyer un nom d'utilisateur et un mot de passe, mais cela se produit dans la connexion TLS dans le cadre d'un protocole interne (par exemple, HTTP). partie du protocole TLS lui-même. L'inconvénient est que vous avez besoin d'un mot de passe distinct pour chaque site, car vous envoyez le mot de passe au serveur. Donc, si vous utilisez le même mot de passe, par exemple Paypal et MyPonyForum, chaque fois que vous vous connectez à MyPonyForum, vous envoyez ce mot de passe au serveur de MyPonyForum afin que l'opérateur de ce serveur puisse l'intercepter, l'essayer sur Paypal et effectuer des paiements en votre nom. .
L'authentification par certificat client offre un autre moyen d'authentifier le client dans une connexion TLS. Contrairement à la connexion par mot de passe, l'authentification par certificat client est spécifiée dans le cadre du protocole TLS. Cela fonctionne de la même manière que le client authentifie le serveur: le client génère une paire de clés publique privée et soumet la clé publique à une autorité de certification approuvée pour la signature. L'autorité de certification renvoie un certificat client pouvant être utilisé pour authentifier le client. Le client peut désormais utiliser le même certificat pour s’authentifier auprès de différents serveurs (par exemple, vous pouvez utiliser le même certificat pour Paypal et MyPonyForum sans risquer de l’abuser). La façon dont cela fonctionne est que, une fois que le serveur a envoyé son certificat, il demande également au client de fournir un certificat. Une certaine magie de clé publique se produit ensuite (si vous voulez connaître les détails lus RFC 5246 ) et que le client sait maintenant qu'il communique avec le bon serveur, le serveur sait qu'il communique avec le bon client et matériel de clé commune pour chiffrer et vérifier la connexion.
De manière bidirectionnelle, le client demande le certificat numérique du serveur et le serveur demande la même chose du client. Il est plus sécurisé que les deux sens, bien que ce soit un peu lent. Généralement, nous ne le suivons pas car le serveur ne se soucie pas de l'identité du client, mais un client doit s'assurer de l'intégrité du serveur auquel il se connecte.