TLS-RSA contre TLS-ECDHE-RSA contre DH statique
Je comprends qu'il y a beaucoup d'articles expliquant ce sujet et, avant de poster ma question, voici ma compréhension actuelle à ce sujet:
ECDHE-RSA = Le serveur génère aléatoirement une paire de clés DH car le certificat n'a pas suffisamment d'informations à envoyer au client pour la génération du secret principal. La clé publique DH est envoyée dans un paquet "échange de clés de serveur". Le secret ne sera jamais envoyé sur le fil. Le "RSA" dans la suite de chiffrement fait référence à la signature de clé publique DH aléatoire, mais pas à la signature du certificat.
DH statique = Le serveur a une clé publique DH fixe dans le certificat, elle sera utilisée par le client pour la génération de secret partagé. Le secret ne sera jamais envoyé sur le fil. Ces informations étant suffisantes, le message d'échange de clés du serveur n'est pas nécessaire.
RSA = Le client utilisera la clé publique du serveur pour crypter le PMS et l'envoyer au serveur. Le serveur déchiffrera le PMS et générera le même PMS. Le secret est envoyé sur le fil.
Mettez de côté le DH statique pour l'instant car il n'est pas couramment utilisé sur Internet - je ne peux pas en trouver un avec Wireshark.
Voici ma question:
Je compare le pcap entre TLS-RSA et TLS-ECDHE-RSA, constatant que:
Dans le certificat présenté par le serveur, les deux contiennent une clé publique RSA (clé publique soumise) et le certificat a une signature RSA (Sha256withRSAencryption)
Dans le paquet "échange de clés de serveur" pour TLS-ECDHE-RSA, il y a une clé DH avec signature RSA.
La signature RSA pour la "clé dh" et le "certificat" est utilisée à des fins d'authentification/signature numérique pour que le serveur prouve qu'il est bien celui qu'il prétend être.
"Clé publique RSA" dans le certificat, pour TLS-RSA, est utilisée par le client pour crypter le PMS. Il peut être vu dans le paquet "échange de clés client". Alors, quelle est sa fonction dans le cas de TLS-ECDHE-RSA?
Je suppose que vous en parlez dans le contexte de TLS, en particulier des chiffrements TLS. Il semble y avoir une certaine confusion autour de ce que fait chaque composant. Il est plus facile de comprendre si vous voyez l'image entière alors la voici.
Lors d'une négociation TLS, les choses suivantes se produisent: authentification, échange de clés. Les détails à ce sujet dépendent de la soi-disant suite de chiffrement. Voici un exemple.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Cela dit essentiellement ce qui suit.
- Le serveur servira un certificat, qui contient une clé publique [~ # ~] rsa [~ # ~] . Ce sera utilisé pour l'authentification.
- L'échange de clés se fera en utilisant [~ # ~] ecdhe [~ # ~] .
- Le chiffrement symétrique utilisé après l'échange de clés sera AES-GCM avec un 128 clé de bit.
- Le PRF (fonction pseudo-aléatoire) à utiliser pendant l'échange est SHA256 (il peut également indiquer le MAC avec des versions TLS plus anciennes).
Regardez attentivement et vous verrez comment tous ces éléments sont représentés dans la suite de chiffrement.
Voyons maintenant ce que cela pourrait signifier: ECDHE-RSA , DH statique , [~ # ~] rsa [~ # ~]
ECDHE-RSA = le serveur génère aléatoirement une paire de clés DH car le certificat n'a pas suffisamment d'informations à envoyer au client pour la génération du secret principal. La clé publique DH est envoyée dans le paquet "échange de clés de serveur". Le secret ne sera jamais envoyé dans le fil. Le "RSA" dans la suite de chiffrement fait référence à la signature de clé publique DH aléatoire, mais pas à la signature de certificat
Vous êtes sur la bonne voie ici, et maintenant, avec la connaissance de l'image entière, il est plus facile de comprendre cela. Lors d'un échange de clé "classique", la clé publique du certificat (et sa paire privée) est utilisée pour convenir d'une clé symétrique. Cependant, cela crée des problèmes si la clé du serveur est jamais compromise. Si une clé privée correspondant à la clé publique du certificat est volée, le trafic précédemment enregistré peut être décrypté facilement.
C'est quelque chose que nous voulons généralement éviter. Entrez Forward Secrecy . Le protocole introduit la possibilité d'avoir un échange de clés séparé qui ne dépend pas beaucoup de la paire de clés RSA. L'algorithme habituellement utilisé pour cela est appelé Diffie-Hellman .
Pour que DH fonctionne, vous avez besoin des soi-disant paramètres DH, qui sont essentiellement un module premier et un générateur. Ces paramètres sont publics. Ceux-ci sont précalculés pendant la configuration du serveur et partagés avec chaque client lors de l'échange de clés. Les clients en coopération avec le serveur utilisent ensuite ces paramètres pour se mettre d'accord sur une clé sans réellement l'envoyer par câble, comme vous l'avez dit. Voici une grande vidéo à ce sujet de la Khan Academy. La clé privée de la paire de clés DH est essentiellement le numéro privé de la vidéo. Alors que la clé publique est ce qui est envoyé sur le fil.
Pour résumer, ECDHE est Ephemeral Elliptic Curve Diffie-Hellman, qui est DH sur des courbes elliptiques. La partie éphémère fait référence au fait que chaque connexion utilise une paire de clés DH.
Le serveur DH statique = possède une clé publique DH fixe dans le certificat, il sera utilisé par le client pour la génération du secret de partage. Le secret ne sera jamais envoyé dans le fil. Les informations étant suffisantes, aucun message d'échange de clé de serveur n'est nécessaire
DH statique fait référence au serveur qui choisit la même paire de clés DH pour chaque connexion client (numéro privé dans la vidéo). Ou, comme vous l'avez suggéré, il peut être intégré au certificat. Cela permet une surveillance passive des connexions TLS. Cela désactive essentiellement le secret de retransmission.
RSA = Le client utilisera la clé publique du serveur pour crypter le PMS et l'envoyer au serveur, le serveur décryptera le PMS et générera le même PMS. Le secret est envoyé dans le fil
Exactement.
Maintenant, arrivons à votre question.
"Clé publique RSA" dans le certificat, pour TLS-RSA, est utilisée par le client pour crypter le PMS. Il peut être vu dans le paquet "échange de clé client". Alors quelle est sa fonction dans le cas de TLS-ECDHE-RSA?
Maintenant, c'est facile de répondre. Lorsqu'il existe un algorithme d'échange de clés explicite, la clé du certificat (clé publique RSA dans ce cas) n'est utilisée que pour l'authentification. Assurez-vous que vous vous connectez à l'hôte auquel vous avez l'intention de valider la chaîne de certificats et vérifiez que le serveur détient la clé privée de la clé publique du certificat donné. Il signera également la clé publique DH qu'il envoie au client avec sa clé privée RSA, que le client vérifie pendant la prise de contact.
"RSA" dans la suite de chiffrement fait référence à la signature de clé publique DH aléatoire, mais pas à la signature de certificat
"RSA" fait référence à la fois à la signature de la clé DH et à la clé publique du certificat de serveur.
Les clés utilisées pour signer/vérifier la clé publique DH proviennent de l'échange de certificats, ou nous ne pouvons pas nous assurer que nous utilisons la clé publique réelle du serveur.
le certificat a une signature RSA (Sha256withRSAencryption)
Quant à l'algorithme de signature du certificat (Sha256withRSAencryption), il appartient à l'émetteur du certificat serveur et est utilisé pour vérifier le certificat serveur. Il ne participe pas à l'échange réel de données et n'est pas pertinent ici.
Alors quelle est sa fonction dans le cas de TLS-ECDHE-RSA?
Comme vous l'avez souligné, "ECDHE" s'assure que la clé secrète symétrique n'est pas envoyée sur le fil. Ainsi, même si la clé secrète du certificat de serveur est compromise un jour, la clé secrète précédemment échangée ne sera pas déchiffrée et les données précédemment envoyées resteront en sécurité. Il est connu sous le nom de "secret ultime".