L'usurpation d'un certificat signé par une autorité de certification est-elle possible?
Je n'avais jamais pensé à cette situation auparavant, je me trompe peut-être complètement mais je vais quand même devoir la clarifier. Lorsqu'une communication démarre avec un serveur, lors de la prise de contact client, le client reçoit une copie de la clé publique (signée CA). Maintenant, le client a un accès complet à cette clé publique qui est signée par l'AC.
Pourquoi ne pas pouvoir attaquer un attaquant, configurer son propre serveur et utiliser cette clé publique qui ferait essentiellement croire à la victime qu'il est le serveur réel. L'attaquant n'a bien sûr pas la clé privée pour décrypter la communication, mais cela n'empêche pas la prise de contact de se produire. Étant donné que le certificat est signé, lorsque ce certificat atteint le navigateur de la victime, cela va dire que le certificat est bien.
Qu'est-ce que j'oublie ici ?
La poignée de main comprend ces étapes (approximatives):
- Le serveur envoie sa clé publique.
- Le client crypte les informations de configuration avec cette clé publique et les renvoie au serveur.
- Le serveur déchiffre la soumission du client et l'utilise pour dériver un secret partagé.
- Les étapes suivantes utilisent ce secret partagé pour configurer le cryptage réel à utiliser.
Donc, la réponse à votre question est, car un imposteur ne peut pas effectuer l'étape 3 (car il n'a pas la clé privée), il ne peut jamais passer à l'étape 4. Il n'a pas le secret partagé, il peut donc ' t terminer la poignée de main.
Asudhak, ne vous sentez pas mal si c'est un peu déroutant. Inventer cryptographie asymétrique était une énorme avancée en mathématiques. Cela semble très contre-intuitif sinon impossible à droite quand on le rencontre pour la première fois.
Lorsqu'un client (souvent un navigateur Web) et un serveur (souvent un navigateur Web) souhaitent établir un canal de communication sécurisé, ils effectuent ce qu'on appelle un "échange de clés".
La clé publique que le serveur fournit au programme client ne contient rien de secret. Sa seule fonction est de crypter les informations.
Le client génère un mot de passe secret unique que seul le navigateur Web connaît. Le client utilise ensuite la clé publique du serveur pour crypter qui utilise une fois le mot de passe secret. La clé publique ne peut que crypter , la clé publique ne peut pas décrypter !
Le client peut transmettre en toute sécurité ce mot de passe secret crypté au serveur. Tout homme du milieu qui pourrait intercepter cet échange de clés ne gagnera aucune information utile car il ne peut certainement pas déchiffrer ce secret à usage unique généré par le client et chiffré avec la clé publique du serveur.
Le serveur, et seul le serveur possède la clé privée correspondante. La clé privée du serveur ne peut être utilisée que pour décrypter . La clé privée du serveur n'est jamais transmise à personne!
Le serveur utilise la clé privée pour déchiffrer le mot de passe secret à usage unique généré par le client (navigateur Web).
Le client et le serveur maintenant connaissent tous deux un secret que personne d'autre ne connaît !
En utilisant ce secret, ils peuvent chiffrer leurs conversations ultérieures en utilisant n'importe quel algorithme de chiffrement symétrique traditionnel avec un haut degré de confiance que le canal est sécurisé.
De plus, le client dispose d'un magasin de ' certificats ' qui contient les clés publiques des organisations auxquelles il fait confiance. Les échanges de clés TLS réels échoueront si le serveur ne présente pas de document numérique appelé certificat contenant une valeur de hachage chiffrée avec la clé privée de l'organisation de confiance. Le client peut utiliser ce hachage et la clé publique de confiance pour savoir que ce serveur est considéré comme fiable.
Vous ne seriez pas en mesure de terminer la prise de contact TLS lorsque le client prend le certificat public du serveur et l'utilise pour crypter un PreMasterSecret utilisé pour générer le Master Secret.
Le client répond avec un message ClientKeyExchange, qui peut contenir un PreMasterSecret, une clé publique ou rien. (Là encore, cela dépend du chiffrement sélectionné.) Ce PreMasterSecret est chiffré à l'aide de la clé publique du certificat de serveur.
Le client et le serveur utilisent ensuite les nombres aléatoires et PreMasterSecret pour calculer un secret commun, appelé "secret principal". Toutes les autres données clés de cette connexion sont dérivées de ce secret principal (et des valeurs aléatoires générées par le client et le serveur), qui est transmis via une fonction pseudo-aléatoire soigneusement conçue.
Rappelez-vous qu'en cryptographie asymétrique, la clé publique n'est en aucun cas un secret et en général (en supposant qu'il n'y a pas d'autres défauts) n'est d'aucune utilité pour un attaquant.
Les réponses existantes parlent de chiffrement avec la clé publique du certificat, qui n'est pas toujours ce qui est réellement utilisé (en particulier avec les suites de chiffrement DSA ou DHE). (Il y a une réponse avec plus de détails ici , par exemple.)
Le but immédiat de la négociation SSL/TLS est d'établir un secret de pré-master de partage entre le client et le serveur. Ce secret pré-maître est ensuite dérivé en un secret maître puis en clés de chiffrement (et MAC). Cette procédure est plus généralement appelée échange de clés (voir RFC 4346 Appendice F.1.1 ).
Pour vous assurer que vous communiquez avec la bonne personne, vous devez utiliser une suite de chiffrement qui prend en charge l'échange de clés authentifiées . (Les suites de chiffrement anonymes sont désactivées par défaut dans les configurations sensibles.)
Cet échange de clés authentifiées se divise en deux catégories:
Échange de clés RSA (par exemple
TLS_RSA_WITH_AES_128_CBC_SHA): le client crypte le secret pré-maître à l'aide de la clé publique du serveur (trouvée dans le certificat). Seul le serveur légitime peut déchiffrer cela avec sa clé privée.Échange de clés DHE (par exemple
TLS_DHE_RSA_WITH_AES_256_CBC_SHAou suites de chiffrement avec un DSS): un échange de clé Diffie-Hellman a lieu. C'est généralement Ephemeral DH, la variante à paramètres fixes (DH, pas DHE) est très rare. (Le fait d'avoir un certificat basé sur RSA n'implique pas un échange de clé RSA.) Le serveur signe ses paramètres DH et le client vérifie la signature par rapport à la clé publique dans le certificat de serveur. Étant donné que seul le serveur légitime a pu signer avec sa clé privée, l'échange est authentifié.
Une méthode utilise le chiffrement, l'autre utilise la signature numérique, les deux utilisant la clé publique dans le certificat. Les deux ont le même résultat final: un secret pré-maître que le client peut partager exclusivement avec le serveur qui a la clé privée pour son certificat.
(Bien sûr, l'autre point est que le client doit vérifier qu'il approuve le certificat pour être valide et délivré au serveur avec lequel il souhaite communiquer, mais ce sont des points légèrement distincts.)
Cela suppose que vous connaissez les bases de l'authentification par clé publique et comment un navigateur Web communique avec un serveur Web via un nom de domaine. L'interaction se fait entre le navigateur Web de l'utilisateur et le serveur Web de l'entreprise.
Clés publiques et clés privées
Le serveur Web possède une clé publique et une clé privée. La clé privée peut déchiffrer un message chiffré par la clé publique. La clé publique peut déchiffrer un message chiffré par la clé privée. L'autorité de certification possède sa propre clé publique et sa propre clé privée.
Le serveur Web envoie ses informations d'entreprise, sa clé publique et le nom de domaine (à associer au certificat SSL) à l'autorité de certification. L'autorité de certification envoie un message de confirmation à l'adresse e-mail associée au nom de domaine, afin de prouver que cette demande a été faite par le véritable propriétaire du nom de domaine. À ce stade, l'autorité de certification attendra que le propriétaire du nom de domaine valide la demande par e-mail.
Signature du certificat
L'autorité de certification chiffre le nom de domaine, les informations sur l'entreprise et la clé publique du serveur Web à l'aide de leur propre clé privée. L'autorité de certification envoie le résultat chiffré au serveur Web. Ce résultat est le certificat SSL, un message texte contenant le nom de domaine, les informations sur la société et la clé publique du serveur Web qui ont tous été chiffrés avec la clé privée de l'autorité de certification. Le serveur Web envoie ce certificat au navigateur de l'utilisateur.
Autorités de certification de confiance
Le navigateur Web est livré préchargé avec une liste des autorités de certification de confiance et leurs clés publiques. Le navigateur Web déchiffre le certificat à l'aide de la clé publique de l'autorité de certification correspondante. À ce stade, le navigateur Web sait que le certificat et son contenu sont fiables car seul un message chiffré avec la clé privée de l'autorité de certification aurait pu être déchiffré de manière cohérente par la clé publique de cette autorité de certification.
Le navigateur Web connaît désormais les informations sur la société de confiance, la clé publique et le nom de domaine qui sont censés être associés au serveur Web, ce qui est toujours suspect. Le navigateur Web confirme que le nom de domaine sur le certificat correspond au nom de domaine réel du serveur Web.
À ce stade, si les noms de domaine correspondent, le navigateur Web détermine que le serveur Web est suffisamment fiable pour envoyer des données chiffrées. Toujours à ce stade, le navigateur Web détermine qu'il peut utiliser la clé publique de confiance du certificat pour crypter ses messages car seule la clé privée du serveur Web authentique peut décrypter ce message.
Notez que si une clé publique non approuvée a été utilisée (sans passer par la vérification de l'autorité de certification), le navigateur Web peut avoir chiffré et envoyé des informations sensibles uniquement pour être déchiffré par la clé privée d'un serveur malveillant! En d'autres termes, il est impératif que la clé publique soit approuvée car le cryptage d'un message avec elle est la seule ligne de défense d'écoute pour les informations que le navigateur Web envoie.
Ensuite, le navigateur Web crypte son message à l'aide de la clé publique de confiance et envoie le message chiffré au serveur Web. Le serveur Web déchiffre le message avec la véritable clé privée, s'il en a une, puis lit le message déchiffré avec succès.
Clé secrète partagée
Lorsque le serveur Web répond au navigateur Web, ce message doit également être envoyé en toute sécurité. Le navigateur Web peut copier ce que le serveur Web vient de faire (à l'exclusion du processus d'autorité de certification) en générant une clé publique et une clé privée pour lui-même, puis en envoyant sa clé publique au serveur Web. Cela établirait une connexion sécurisée appelée cryptage asymétrique bidirectionnel. Cependant, une telle communication est un fardeau informatique (relativement parlant).
L'approche standard consiste donc à utiliser une clé secrète partagée qui peut crypter un message et également le décrypter. Le navigateur Web génère une clé secrète, la chiffre à l'aide de la clé publique de confiance, puis l'envoie au serveur Web. Si le serveur Web est authentique, il pourra décrypter la clé secrète avec succès.
À ce stade, à la fois le navigateur Web et le serveur Web ont une clé secrète partagée qu'ils peuvent désormais utiliser pour crypter et décrypter d'autres communications.
Pour en savoir plus:
Vérification de l'intégrité du message avec des fonctions de hachage pour détecter les altérations de message
Chaîne de confiance entre les autorités de certification
La raison pour laquelle vous ne pouvez pas simplement prendre la clé publique signée et l'utiliser pour intercepter le trafic dans une attaque de type homme du milieu est que vous (ou l'attaquant) ne disposerez pas de la clé privée correspondante qui va avec la clé publique .
Ainsi, le navigateur recevra les serveurs Web ou la clé publique signée par l'autorité de certification, et l'utilisera pour crypter son propre secret à renvoyer au serveur Web.
Le serveur Web possède la clé privée correspondante nécessaire pour déchiffrer les données renvoyées par le navigateur qui a été chiffré avec la clé publique, l'attaquant ne le fait pas, il ne pourra donc pas déchiffrer le trafic.
En fait, j'ai posé cette question en 2012, mais maintenant en 2015, il y a en fait une attaque qui rend cela possible. Selon l'implémentation, les clients peuvent être vulnérables à cette attaque, ce qui peut permettre à un attaquant, un MiTM, d'usurper tout certificat signé qu'il souhaite.
https://www.smacktls.com/ fournit une explication détaillée de la façon dont cela fonctionne en raison d'une mauvaise implémentation de la machine d'état SSL sur le client.
Que le certificat CA (clé publique) pour les certificats vérifiés est déjà inclus dans le navigateur et que votre scénario générerait un avertissement SSL.
Si vous parlez de quelque chose comme SSH, vous devrez toujours accepter la clé publique. Si vous ne vérifiez pas que cette clé est correcte via un autre canal sécurisé, c'est votre faute si vous êtes MITM'ed.