SSL: Comment les certificats sont-ils protégés contre les attaques intermédiaires?

Question

Ma question concerne les certificats spécifiquement dans ssl mais je pense que les questions devraient s'appliquer à tous les certificats. J'ai inclus la procédure SSL dans un souci de clarté.

Dans SSL ce que je crois être la procédure:

1) Client

• envoie des algorithmes de chiffrement pris en charge
• envoie client nonce

2) Serveur

• Choisit (et envoie) un
  • algorithme symétrique
  • un algorithme à clé publique
  • un algorithme MAC
• envoie son certificat
• envoie au serveur nonce

3) Client

• vérifie le certificat
  • Extraits clé publique
• Génère une clé secrète pré-maître (pms)
• Crypte avec des serveurs clé publique et envoie

4) client et serveur

• Compute maître sécrètent (MS) de PMS et nonces
• PMS coupés en tranches pour générer deux chiffrement & deux clés mac

5) client

• envoie un mac de tous les poignées de main (pour assurer leur n'étaient pas auparavant modifide)

6) serveur

• envoie un mac de tous les poignées de main

Question

Ce qui empêche un homme dans l'attaque du milieu de se produire à l'étape deux?Pourquoi un homme au milieu, disons trudy, ne peut-il pas capturer le certificat envoyé par le serveur et y changer la clé publique (à quelque chose à qui il a la clé privée). Je suppose que le certificat est crypté d'une manière ou d'une autre.

Toutefois, le serveur ne peut pas crypter le certificat car le client n'a pas encore la clé publique. Lorsque le serveur reçoit la clé d'une autorité (comme veri-sign), la clé est-elle pré-encodée en utilisant la clé publique de verisign? Je pense que cela devrait fonctionner parce que tous les navigateurs Web devraient avoir les clés publiques de la plupart des autorités.

Answer 1

Non, le certificat n'est pas crypté. Mais il est signé par une autorité de certification (CA). Puisque ceux-ci vérifient les informations incluses dans le certificat (en particulier l'URL à laquelle le cert appartient), il ne devrait pas y avoir un deuxième certificat valide pour une URL donnée.

Le certificat de l'autorité de certification est vérifié par rapport à un fichier de clés certifiées (par exemple dans votre navigateur). Si ce fichier de confiance est compromis, ou si vous faites confiance à des certificats non valides, il n'y a pas de protection contre les attaques du milieu

Answer 2

Les certificats sont signés par une autorité de confiance, telle que Verisign.

Les certificats pour ces autorités racine sont intégrés dans les navigateurs lorsque vous les téléchargez. Vous pouvez afficher les certificats racine dans Firefox, par exemple, en allant à tools -> options -> advanced -> encryption -> view certificates -> autorités.

Si l'une de ces autorités de certification racine est compromise, vous avez raison de croire qu'un certificat peut être falsifié, ce qui rend possible une attaque de type man-in-the-middle.

Answer 3

Vous avez en fait signalé un point faible de l'ICP.

Say Trudy est au milieu de vous et yourbank (bank.com). Trudy peut changer la clé publique à volonté à l'étape 2 mais la signature du certificat sera invalide. Donc, Trudy doit trouver un moyen de générer à nouveau la signature. Il est sûr de dire que les CA de confiance ne le feront pas pour lui. Il doit donc signer avec une fausse AC, qui n'est pas approuvée par votre navigateur. C'est toujours sûr en théorie. Cependant, la plupart des navigateurs (en particulier IE 6) affichent un avertissement de sécurité vague et la plupart des gens ne comprennent pas et ignorent simplement, selon certains tests.