Authentification SSL par comparaison de l'empreinte du certificat ?

Question

Question pour tous les experts en SSL :

Nous disposons d'un dispositif intégré doté d'un petit serveur web et nous pouvons y installer nos propres certificats SSL auto-signés. Le client est écrit en .NET (mais cela n'a pas beaucoup d'importance).

Comment puis-je authentifier le dispositif dans .NET ? Est-il suffisant de comparer l'empreinte digitale du certificat contre une entrée connue dans la base de données ?

Si je comprends bien, l'empreinte digitale est un hachage de l'ensemble du certificat, y compris la clé publique. Un appareil se faisant passer pour le mien pourrait bien sûr envoyer le même certificat public, mais il ne pourrait pas connaître la clé privée, n'est-ce pas ?

Ou dois-je établir ma propre chaîne de confiance, créer mon propre certificat racine de l'autorité de certification, signer le certificat du serveur web et l'installer sur le client ?

Answer 1

Ce que vous proposez est en principe acceptable. Elle est par exemple utilisée lors de principales parties signataires . Dans ce cas, les participants échangent simplement leur nom et les empreintes digitales de leurs clés publiques et s'assurent que la personne présente à la fête est bien celle qu'elle prétend. Il est beaucoup plus facile de vérifier les empreintes digitales que de vérifier une longue clé publique.

Un autre exemple est celui de la soi-disant Système de fichiers auto-certifié . Là encore, seuls les hashs des clés publiques sont échangés sur un canal sécurisé. (Dans ce schéma, les clés publiques n'ont pas besoin d'être envoyées de manière sécurisée. Le récepteur doit seulement vérifier que le hachage des clés publiques correspond aux hachages intégrés dans les URL. Bien entendu, le récepteur doit également s'assurer que ces URL proviennent d'une source fiable.

Ce schéma et ce que vous proposez sont plus simples que l'utilisation d'une AC. Mais il y a un inconvénient. Vous devez vous assurer que votre base de données avec les hachages est authentique. Si votre base de données est importante, cela sera probablement difficile. Si vous utilisez des AC, vous devez seulement vous assurer que les clés racine sont authentiques. Cela simplifie généralement la gestion des clés de manière significative et c'est bien sûr l'une des raisons pour lesquelles les systèmes basés sur les AC sont plus populaires que, par exemple, le système de fichiers auto-certifié mentionné ci-dessus.

Answer 2

De la même manière que vous ne considéreriez pas et ne devriez pas considérer que deux objets sont égaux simplement parce que leurs codes de hachage correspondent, vous ne devriez pas considérer qu'un certificat est authentique simplement parce que son empreinte digitale figure dans une liste d'"empreintes digitales de certificats connus".

Les collisions font partie de la vie des algorithmes de hachage, même les bons, et vous devez vous prémunir contre la possibilité qu'un attaquant motivé puisse créer un certificat frauduleux avec un hachage d'empreinte digitale correspondant. La seule façon de se prémunir contre cela est de vérifier la validité du certificat lui-même, c'est-à-dire de vérifier la chaîne de confiance comme vous le sous-entendez dans votre dernière déclaration.

Answer 3

Court :

En théorie, vous faites alors exactement ce qu'une autorité de certification fait pour vous. Donc ça devrait aller.

Plus long :

Lorsqu'une autorité de certification signe votre demande de clé publique/certificat/certificat, elle ne signe pas l'ensemble des données du certificat. Mais seulement la valeur de hachage calculée de l'ensemble des données du certificat. Ainsi, la signature reste petite.

Lorsque vous ne voulez pas établir votre propre CA ou utiliser un CA commercial/gratuit - en comparant l'empreinte digitale avec celle de votre CA de confiance, vous obtiendrez la deuxième configuration la plus fiable. La solution la plus fiable consiste à comparer l'ensemble du certificat, car elle vous protège également des attaques par collision de hachage.

Comme l'ont dit d'autres personnes ici, vous devez vous assurer d'utiliser un algorithme de hachage sûr. SHA-1 n'est plus sûr.

des informations plus détaillées sur ce sujet :

• https://security.stackexchange.com/questions/6737
• https://security.stackexchange.com/questions/14330