Les certificats sans DNS sont-ils fondamentalement défectueux?
Je suis nouveau dans le domaine de la sécurité et j'implémente le design de quelqu'un d'autre. La conception nécessite un serveur TCP avec TLS dans un environnement où il n'y a pas de DNS, uniquement des IP.
Je travaille avec une chaîne de certificats typique (certificat racine auto-signé -> certificat intermédiaire -> certificat Endpoint). Le serveur TCP présente le certificat Endpoint à un client dont la partie publique du certificat intermédiaire est épinglée dans son code. Lorsque le client se connecte, il vérifie que le certificat intermédiaire a été utilisé pour signer le certificat Endpoint cert.
Donc, si je comprends bien, lorsque le client se connecte, un échange de clés se produit pour sécuriser la communication et le client utilise ensuite la vérification de la chaîne de certificats pour vérifier que le serveur est bien qui il dit être. Cependant, dans ce schéma, un imposteur ne pourrait-il pas simplement présenter le certificat après l'avoir obtenu du vrai serveur?
Suis-je en train de mal comprendre cela comme un défaut? D'après ma compréhension, sans nom DNS auquel lier le certificat, la vérification de la chaîne (avec un certificat parent signé épinglé ou non) n'est pas suffisante. Peut-on faire autre chose ici?
Cependant, dans ce schéma, un imposteur ne pourrait-il pas simplement présenter le certificat après l'avoir obtenu du vrai serveur?
Un imposteur ne peut pas présenter et tirer parti du vrai certificat du serveur à moins qu'il possède également la clé privée correspondante . Ceci est true que l'entrée DNS SAN DNS ou IP soit utilisée pour identifier le certificat présenté.
Lorsque l'attaquant envoie le certificat du serveur, le client crypte un secret partagé (utilisé pour générer la clé de cryptage symétrique pour la session) avec la clé publique de ce certificat. L'attaquant ne pourra alors pas récupérer le secret car il ne dispose pas de la clé privée du certificat, il ne pourra donc pas terminer la négociation TLS.
Pour trouver l'inspiration, regardez comment SSH l'échange de clés fonctionne:
Le client gère une table de "serveurs connus" qui fait correspondre une adresse IP à un hachage. Lors de la connexion à un serveur, le client reçoit le certificat de serveur (clé publique) et en calcule le hachage, et recherche l'adresse IP du serveur dans la table "serveurs connus".
Si le client a déjà vu ce serveur, il peut comparer le hachage calculé du certificat avec celui qu'il a enregistré pour le serveur. S'ils correspondent, alors tout va bien et la connexion continue. Sinon, le programme SSH affichera un gros message d'avertissement et refusera de se connecter.
Lorsque le client se connecte à un serveur pour la première fois, l'utilisateur est informé que nous n'avons jamais vu ce serveur auparavant et propose d'ajouter le certificat du serveur à sa table de serveurs connue. Cette étape peut être contournée en entrant manuellement les détails du certificat du serveur dans la table des serveurs connus.