Comment l'authentification bidirectionnelle utilisant SSL fonctionne-t-elle?
Disons qu'Alice veut utiliser un service Web sur Bob.
Bob est sur bob.in.wonderland.com
Alice ouvre une connexion à bob.in.wonderland.com:443. Pris par DNS lapin magique, Alice arrive sur le port 443 à 69.64.156.40.
Alice demande un certificat et Bob présente son, délivré par Diginotar à bob.in.wonderland.com. Comme Alice fait confiance à Diginotar, elle est assurée qui parle bien à Bob.
Mais Bob veut confirmer si Alice est dans son whitelist.
Pour l'instant, tout BOB sait qu'il a reçu une connexion de l'adresse IP 66.147.244.191.
Il demande un certificat et est présenté avec un, délivré par Verisign pour alice.in.wonderland.com.
Quel bob fait maintenant?
Fait-il un DNS inverse sur 66.147.244.191 Pour voir si cela s'appelle alice.in.wonderland.com?
Et si -Alice est derrière un proxy Squid?
Je suppose que le modèle de menace est qu'il peut y avoir un attaquant homme-moyen entre Alice et Bob, et que Alice et Bob ne sont pas sur le même sous-réseau de confiance. C'est ce que SSL/TLS est conçu pour protéger contre, et c'est pourquoi Alice doit vérifier le certificat de Bob dans votre exemple (au moins).
Du point de vue de Bob, vérifiant que la demande d'Alice provient d'une adresse IP connue n'est pas très utilisée. Les attaquants pourraient forger et modifier des paquets pour les faire ressembler à leur adressage IP qu'ils souhaitent. Par la suite, les recherches DNS sont également inutiles: tout ce dont vous aurez besoin est de vous assurer de forger les paquets d'utiliser une adresse IP avec l'entrée DNS correcte.
Lorsque BOB demande un certificat client d'Alice lors de la poignée de main SSL/TLS, cela fera également l'envoi d'Alice et utilise sa clé privée pendant la poignée de main SSL/TLS pour affirmer son identité. Lorsque la poignée de main est terminée avec succès, Bob saura alors que Alice a la clé privée pour ce certificat et devra vérifier qu'elle fait confiance à ce certificat.
Que la demande vienne ou non de derrière un proxy ou non n'a pas d'importance lorsque vous utilisez SSL/TLS. Un proxy HTTP ne peut que tuner la connexion SSL/TLS à partir du client d'origine au serveur cible.
Ce qui compte pour Bob, c'est comment il va vérifier le certificat d'Alice. En règle générale, cela sera fait à l'aide d'un PKI de la même manière que le certificat d'Alice vérifié Bob, bien que cela ne nécessite pas de même CA que Bob (elle doit être quelque chose que BOB Trusts). Notez que cela n'a pas besoin d'utiliser un PKI non plus. Il est possible de vérifier le certificat contre une liste donnée (si Alice et Bob se sont réunis auparavant, par exemple), mais cela peut être un peu plus complexe puisque Bob peut avoir à modifier la liste des émetteurs acceptés qu'elle envoie (par exemple, envoyez-la un, par exemple. Ce qui est explicitement autorisé par TLS 1.1, mais non spécifié dans les versions précédentes, voir Message de demande de certificat ) et utilisez le code personnalisé pour vérifier que le certificat. (J'ai mis en place ce type de schéma dans le passé et ça marche bien.)
Il y a une exception à cela lorsque vous utilisez ce que j'appellerais "Serveurs de proxy Mitm", c'est-à-dire des serveurs de proxy configurés pour spoofer le serveur SSL/TLS réel en insérant leur propre certificat (voir SSL Bump =). Dans ce cas, le certificat Alice voit ne viendrait pas de Diginotar, mais d'une autre CA (généralement une entreprise d'entreprise lorsque cela se fait sur un réseau local d'entreprise).
Bien qu'Alice puisse s'autoriser de manière à faire confiance à un tel proxy MITM, l'utilisation de certificats client SSL/TLS rendrait BOB réaliser qu'il existe un MITM et la connexion échouerait. En effet, Alice est censé signer toute la poignée de main SSL/TLS (vue par Alice et Bob) dans elle CertificateVerify Message à authentifier avec un certificat client. Étant donné que le proxy MITM aurait remplacé le certificat de Bob, les signatures envoyées par Alice et Bob ne correspondaient pas.
Cela dépendrait de la mise en œuvre spécifique.
En général, Alice agirait comme un client à Bob. Si Bob s'attend à ce que seuls les autres serveurs autorisés de se connecter, Bob vérifierait le certificat de validité, y compris l'expiration, contre les émetteurs CRL et effectuer une recherche inversée contre le nom. Si Bob s'attend à un client d'utilisateur, la recherche inversée sera probablement ignorée ou utilisée uniquement pour la journalisation.
Si Bob s'attend à ce que Alice se connecte à un hôte de confiance connu, Bob s'attendrait à ce que l'adresse IP d'Alice correspond à l'enregistrement DNS. Peu importe que Alice soit derrière un proxy et que Bob ne verra que l'adresse IP du proxy. Donc alice.in.wonderland.com aurait besoin d'être configuré à l'adresse IP externe du proxy.
La partie clé cependant est la suivante:
- Bob aura la clé publique d'Alice déjà mappée sur un identifiant d'une sorte qui sera utilisé pour accorder l'accès aux ressources de Bob.
- Bob et Alice se défieront à envoyer un message à l'autre que chacun ne peut que déchiffrer avec leur clé privée. Prouvant ainsi qu'ils ont le certificat connu et approuvé de chaque côté.
Notez aussi: Si Alice est derrière un proxy, le proxy doit soit avoir soit la clé privée d'Alice (le proxy peut donc parler avec Bob sur le nom d'Alice), soit passer par la connexion d'Alice sans modifier son contenu sans modifier son contenu. .
Référence supplémentaire http://fr.wikipedia.org/wiki/transport_layer_security ou http://tools.ietf.org/html/rfc5246 Pour des détails techniques spécifiques.
J'espère que cela pourra aider.
Pas assez. Une fois la poignée de main SSL terminée, BOB sait qu'il parle à une personne que Verisign a certifié alice.in.wonderland.com. Ce que Bob fait avec ces informations à ce stade est à la hauteur de lui et dépendra de l'application particulière. Quelques exemples:
Bob pourrait avoir une blancheur de clients autorisés à se connecter. Alors Bob regarderait
alice.in.wonderland.comDans cette liste. (Bob pourrait alternativement avoir une liste blanche de clés publiques, mais les certs clients pourraient rendre les choses plus faciles à gérer Bob, car il peut maintenant entrer dans des valeurs lisibles par l'homme dans sa liste blanche.)Bob pourrait traiter
alice.in.wonderland.comComme le nom d'utilisateur d'Alice et la connecte à son compte. En d'autres termes, Bob pourrait avoir une base de données avec une liste d'utilisateurs; Pour chaque utilisateur, il aurait le nom de l'utilisateur (tel que trouvé dans le certificat de l'utilisateur) et toutes les informations associées à cet utilisateur. Une fois que Bob reçoit une connexion de quelqu'un avec nom N, Bob peut rechercher n dans la table et enregistrer automatiquement le client en tant que N. Lorsque quelqu'un crée un nouveau compte, BOB peut créer automatiquement un nouveau compte avec le nom trouvé dans leur certificat ( en supposant que l'on n'existe pas déjà). Le résultat est que les utilisateurs peuvent se connecter au service de Bob, sans avoir besoin d'entrer dans un nom d'utilisateur ou un mot de passe; Leur client certifié est utilisé pour les authentifier.
Encore une fois, cela dépend de l'application; Cela dépend de ce que Bob veut savoir sur l'identité de l'ordinateur dont il parle. Il n'y a pas de réponse unique.