Comment SSH utilise-t-il à la fois RSA et Diffie-Hellman?
Le protocole SSH 2 vous permet d'utiliser les clés DSA, ECDSA, ED25519 et RSA lors de l'établissement d'une connexion sécurisée à un serveur. (Gardez à l'esprit pour cette question que je ne connais que la procédure et les capacités de RSA, et ne peux pas parler pour les autres méthodes)
Ce qui m'embrouille, c'est selon man sshd, Diffie-Hellman est utilisé pour l'échange de clés:
Pour le protocole 2, la sécurité avant est fournie via un accord de clé Diffie-Hellman. Cet accord de clé se traduit par une clé de session partagée. Le reste de la session est chiffré à l'aide d'un chiffrement symétrique ...
Cela conduit à deux questions:
- Où la clé RSA entre-t-elle en jeu si elle n'est pas utilisée pendant l'échange de clé?
- Pourquoi un deuxième protocole (dans ce cas, Diffie-Hellman) est-il nécessaire? Pourquoi ne pas simplement utiliser la clé publique RSA du client pour crypter la clé de session sur le serveur et l'envoyer au client?
La clé Host est utilisée pour signer les paramètres Diffie-Hellman. Il est utilisé lors de l'échange de clés; RSA est un algorithme de signature ainsi qu'un algorithme de cryptage. D'après ce que je peux dire, la clé client (en
authorized_keys) n'est pas du tout utilisé dans l'échange de clés; il est uniquement utilisé après échange de clés pour signer un message particulier et prouver que le client possède la clé privée (un côté des paramètres DH signés suffit pour empêcher un MITM, car l'attaquant ne peut pas se faire passer pour - les deux client et serveur; il est plus facile de faire en sorte que le serveur ait toujours une paire de clés que de faire en sorte que le client ait toujours une paire de clés).La façon dont SSH utilise DH est un algorithme éphémère: les paramètres DH sont générés pour les sessions individuelles et sont détruits dès qu'ils ne sont plus nécessaires. La seule chose pour laquelle la paire de clés durable est utilisée est l'authentification. Cela donne secret ultime: le vol de la clé privée ne vous permet pas de déchiffrer les anciennes sessions.
Si RSA a été utilisé pour chiffrer la clé de session, quelqu'un qui a enregistré cette session, achète le serveur SSH des années plus tard après sa mise hors service et obtient la clé privée de son disque dur peut l'utiliser pour déchiffrer le clé de session et utilisez-la pour lire l'intégralité de la communication. Si RSA est utilisé pour signer les paramètres DH, alors la seule façon d'exploiter une clé privée volée est dans une attaque man-in-the-middle, et qui peut être déjouée par l'opérateur du serveur qui change la clé et informer tous ses utilisateurs des clés modifiées. Avec l'échange de clés éphémères, rien de nécessaire pour déchiffrer une session enregistrée n'est stocké plus longtemps qu'il ne doit l'être.
C'est également une configuration utilisée de plus en plus souvent pour les sessions TLS (là où les certificats ont des dates d'expiration, une clé privée n'a même pas strictement ont à être gardée secrète après son expiration car elle ne devrait pas être possible de l'utiliser dans une attaque d'homme au milieu; c'est parce que les utilisateurs ignoreront les certificats expirés, mais vous pouvez voir pourquoi le cryptage éphémère est agréable).