Quelqu'un peut-il expliquer exactement ce qui est accompli par la génération de paramètres DH?
J'installe un serveur node.js:
https.createServer({
...
ciphers: 'ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH',
honorCipherOrder: true
}, app).listen(443);
Ceci est capable d'obtenir une note SSLLabs A, ce qui est bien. Il semble maintenant que toutes les négociations de la simulation de prise de contact soient effectuées à l'aide de TLS_RSA_WITH_RC4_128_SHA.
RC4 résiste à BEAST. Si nous sommes vulnérables à BEAST, nous ne pouvons pas obtenir la note A.
Je voudrais prendre en charge PFS (forward secrecy) s'il est pris en charge par le client.
Sur la base de ma lecture, je "dois générer un peu d'aléatoire" en générant des paramètres Diffie-Hellman et les intégrer dans mes certificats d'une manière ou d'une autre, avant que le serveur n'implémente correctement ECDHE pour la confidentialité. J'ai lu quelque part que ECDHE est moins gourmand en CPU que DHE, c'est donc un plus.
Eh bien, j'ai beaucoup de questions. Mais je vais poser la première:
Pourquoi dois-je générer "du hasard" pour ajouter aux certificats, à quoi sert-il et à quoi sert réellement la commande? La page OpenSSL sur dhparam ne me dit pas grand-chose sur ce qu'il fait réellement.
J'ai vu cette réponse et je cherche une explication plus claire (ou au moins des références à une lecture pertinente!).
Selon OpenSSL Ciphers il semble que ECDHE soit un chiffrement TLS 1.2. Sur page PFS de Qualys il est dit que ECDHE est pris en charge par tous les principaux navigateurs modernes, et pourtant je ne vois que iOS6 dans les résultats de mon test SSLLabs se connectant via TLS1.2. Je suppose que je peux prendre la section "simulation de poignée de main" avec un grain de sel.
Une autre question est de savoir pourquoi SSLLabs note avec un A si je laisse l'entrée HIGH dans la liste de chiffrement: le serveur prend en charge une connexion, par exemple TLS_RSA_WITH_AES_128_CBC_SHA (le rapport l'indique), vulnérable à BEAST! Peut-être parce qu'il n'a jamais testé avec un "client" qui ne signale aucun support RC4.
Une autre question: sur la page OpenSSL Ciphers, la liste des suites de chiffrement TLS 1.2 comprend:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE-RSA-AES128-SHA256
Cela indique-t-il que si je le connecte avec ECDHE, il est maintenant vulnérable à BEAST également en raison de l'utilisation de CBC? Par exemple. Je devrais changer cela pour faire comme Google: ECDHE avec RC4. Mais la page Chiffres n'inclut rien qui ressemble à ECDHE-RSA-RC4-SHA. Il existe cependant un ECDHE-ECDSA-RC4-SHA. En quoi est-ce différent? Edit: this SO answer mentionne que ECDSA est quelque chose de séparé de RSA. Je voudrais reproduire ce que Google fait avec ECDHE_RSA + RC4 + SHA comme cela semble être le mélange parfait de performances et de sécurité.
Plus de notes (veuillez me dire si j'ai mal compris, en particulier les déclarations déguisées en questions):
La résilience BEAST est contrôlée par la sélection du chiffre symétrique (RC4 vs AES, etc.). Les modes d'AES n'utilisant pas CBC ne sont pas pris en charge par de nombreux clients? Donc, nous devrions simplement éviter complètement AES ...? PFS peut être obtenu en utilisant l'échange de clés Diffie-Hellman, et seuls les modes qui incluent DHE ou ECDHE le satisfont. Seul OpenSSL prend en charge la parfaite parfaite confidentialité. RC4 est plus rapide que AES. RC4 est meilleur que AES (à cause de BEAST)?
Un autre montage: Voyons voir ... ici est une indication que BEAST n'est pas quelque chose trop réaliste, bien qu'il affecte négativement la note SSLLabs. Ce gros "A" a l'air si bon ... Voyons voir ... Je devrais probablement encore mettre les chiffres RC4_128 au début de la chaîne de chiffrement si, pour aucune autre raison, il n'a pas été démontré qu'ils sont "cassés" et sont plus rapide que l'AES en général. Quoi qu'il en soit, je me suis éloigné du sujet d'origine qui est ECDHE. Et comment faire fonctionner correctement les paramètres DH avec Node/Express?
L'échange traditionnel basé sur RSA en SSL est agréable en ce sens qu'une clé de session aléatoire est générée et transmise à l'aide d'un cryptage asymétrique, de sorte que seul le propriétaire de la clé privée peut la lire. Cela signifie que la conversation ne peut être déchiffrée par personne, sauf s'il possède la clé privée du certificat. Mais si un tiers enregistre le trafic chiffré et finit par acquérir la clé privée, il peut l'utiliser pour déchiffrer la clé de session à partir de l'échange SSL, puis l'utiliser pour déchiffrer la session entière. C'est donc pas parfait secret secret.
La clé ici pour Perfect Forward Secrecy est le échange de clés Diffie-Hellman . DH est un algorithme très cool pour générer une clé partagée entre deux parties de sorte qu'un observateur qui voit tout - l'ensemble de l'échange entre les deux parties en clair - ne peut pas dériver la clé uniquement de ce qui est envoyé sur le fil. La clé secrète dérivée est utilisée une fois, jamais stockée, jamais transmise et ne peut plus jamais être récupérée par quiconque. En d'autres termes, parfait secret ultime.
DH seul ne peut pas vous protéger car il est trivial de jouer à l'homme du milieu car il n'y a ni identité ni authentification. Vous pouvez donc continuer à utiliser RSA pour l'authentification et simplement utiliser Diffie-Hellman pour générer la clé de session. C'est DHE-RSA-*, par exemple: DHE-RSA-AES128-SHA1 est une spécification de chiffrement qui utilise Diffie-Hellman pour générer la clé, RSA pour l'authentification, AES-128 pour le chiffrement et SHA1 pour les résumés.
Mais Diffie-Hellman nécessite d'abord certains paramètres de configuration. Ceux-ci ne sont pas secrets et peuvent être réutilisés; De plus, leur création prend plusieurs secondes. Mais ils doivent être "propres", générés par vous afin que vous sachiez qu'ils ne sont pas fournis par un attaquant. L'étape dhparam génère les paramètres DH (principalement un seul grand nombre premier) à l'avance, que vous stockez ensuite pour le serveur à utiliser.
Des recherches récentes ont montré que s'il est difficile de "casser" un échange DH (c'est-à-dire de dériver la clé du trafic), une bonne partie de ce travail difficile peut être effectuée à l'avance simplement en se basant sur les nombres premiers. Cela signifie que si les mêmes DH DH sont utilisés partout, ceux-ci deviennent une cible "principale" pour les agences bien financées pour faire leurs calculs. Cela suggère qu'il y a une certaine sécurité accrue à avoir en générant le vôtre nombres premiers (plutôt que de compter sur ceux fournis avec votre logiciel), et peut-être en recréant ces nombres premiers périodiquement.
Un bit intéressant est que Diffie-Hellman courbe elliptique est un échange Diffie-Hellman modifié qui utilise la cryptographie à courbe elliptique au lieu des grands nombres premiers traditionnels de style RSA. Donc, même si je ne suis pas sûr des paramètres dont il peut avoir besoin (le cas échéant), je ne pense pas qu'il ait besoin du type que vous générez.
Voir également:
En ce qui concerne BEAST
L'attaque BEAST repose sur certains artefacts de la méthode de chaînage de blocs utilisée avec AES sur les anciennes versions de SSL. Les nouvelles versions de SSL font bien les choses, donc ne vous inquiétez pas. RC4 n'est pas un chiffrement par blocs, il n'y a donc pas de chaînage de blocs. L'attaque BEAST est si absurdement difficile à réaliser que ses implications réelles sont décidément inexistantes. En fait, RC4 a ses propres faiblesses, surtout lorsqu'il est maltraité comme l'attaque BEAST devrait le faire. Ainsi, vous n'obtiendrez peut-être pas une meilleure sécurité.
Forcer TLS 1.2 résoudrait certainement tous vos problèmes de sécurité théoriques, tout en empêchant de nombreux visiteurs de se connecter. Pas tout à fait comme ECDHE.
Dans une suite de chiffrement "DHE", le serveur génère à la volée une nouvelle paire de clés Diffie-Hellman , signe la clé publique avec sa clé privée RSA ou DSA ou ECDSA et l'envoie au client. La clé DH est "éphémère", ce qui signifie que le serveur ne la stocke jamais sur son disque; il le garde dans RAM pendant la durée de la prise de contact SSL, puis l'oublie complètement. N'étant jamais stocké, il ne peut pas être volé par la suite, et c'est ce que PFS vient de. Notez que cette entreprise DH n'entre jamais dans le certificat: le certificat du serveur contient la clé publique permanente du serveur, de type RSA ou DSA ou ECDSA, et utilisée uniquement pour les signatures.
Diffie-Hellman, génériquement, est un algorithme calculé dans un groupe fini où les calculs sont faciles, mais logarithme discret est difficile. Dans la DH "simple", le groupe consiste en quelques entiers modulo un grand premier p, avec multiplication comme loi de groupe. Les paramètres DH sont la définition de ce groupe, à savoir le grand premier p et le générateur conventionnel g. Pour des raisons de sécurité, il n'y a aucun problème à réutiliser les mêmes paramètres pour plusieurs paires de clés, notamment en utilisant les mêmes paramètres DH que quelqu'un d'autre. Ce qui est nécessaire, c'est que les paramètres sont "justes", c'est-à-dire que le premier p a été généré de manière aléatoire, et non spécialement conçu pour rendre le logarithme discret facile à modulo ce premier.
La génération de vos propres paramètres DH est un moyen de "s'assurer" que vous utilisez correctement des paramètres DH aléatoires. C'est plus rituel que scientifique, cependant: la bibliothèque du serveur SSL devrait venir avec des paramètres DH par défaut qui sont corrects, et vous avez déjà, par définition, confiance en cette bibliothèque SSL pour ne pas vous jouer de mauvais tours.
[~ # ~] ecdhe [~ # ~] suit les mêmes lignes, sauf qu'il applique DH dans un autre groupe, à savoir un elliptique courbe . Les courbes elliptiques ont certains avantages informatiques, mais sont moins largement prises en charge (pour l'instant). L'analogue de la génération de vos propres paramètres DH serait de choisir votre propre courbe aléatoire. Personne ne fait ça, parce que:
- La génération d'une courbe aléatoire avec des caractéristiques appropriées est une entreprise complexe et coûteuse.
- Les avantages informatiques des courbes elliptiques proviennent en partie de l'optimisation des deux parties (client et serveur) pour une courbe spécifique. Générer votre propre courbe aléatoire irait à l'encontre de cela.
Quant à BEAST, ne vous en faites pas trop. Il s'agit d'une attaque sur le client, pas sur le serveur, et les clients modernes incluent des solutions de contournement (le "1/n-1 split", en particulier). C'est une belle attaque, mais ça ne marche plus. La seule chose que le serveur pouvait faire était de forcer un ancien client inconscient à utiliser RC4 (qui n'est pas vulnérable par construction).
Notez que BEAST s'applique uniquement à SSL 3.0 et TLS 1.0. Avec TLS 1.1 et 1.2, BEAST ne fonctionne pas du tout, même si le chiffrement symétrique est un chiffrement par bloc en mode CBC.
RC4 résiste à BEAST.
IL est vrai que l'utilisation d'un chiffrement de flux évite BEAST et POODLE, mais RC4 a ses propres problèmes. Le flux de clés a des biais connus qui peuvent divulguer des informations.
RC4 a été brièvement recommandé pendant un certain temps après la découverte de la bête, mais avant de se rendre compte à quel point les problèmes de biais de flux de clés dans RC4 étaient graves.
Si nous sommes vulnérables à BEAST, nous ne pouvons pas obtenir la note A.
Cela a pu être vrai à un moment donné, ce n'est plus le cas.
Les gars qualys jugent la bête comme étant un moindre mal que RC4.
Pourquoi dois-je générer "un peu de hasard" à ajouter aux certificats, à quoi sert-il et à quoi sert réellement la commande? La page OpenSSL sur dhparam ne me dit pas grand-chose sur ce qu'il fait réellement.
dhparam génère des paramètres utilisés pour diffie-hellman conventionnel (pas ECDH). Ces paramètres ne sont pas secrets mais pour que DH soit sécurisé, ils doivent remplir certaines conditions. Il y a plusieurs raisons pour lesquelles vous voudrez peut-être générer vos propres paramètres.
- Les paramètres fournis avec votre logiciel peuvent être trop courts. Bien que 1024 bits dh n'ait pas été publiquement rompu, il est suspecté que certains attaquants bien financés l'aient fait.
- Une grande partie du travail de craquage de dh se fait par ensemble de paramètres et non par session. Ainsi, l'utilisation des mêmes paramètres que tout le monde permet à un attaquant de réutiliser son travail pour casser de nombreuses sessions de différents serveurs.
- Il est possible de créer des paramètres de porte dérobée qui peuvent être facilement piratés par l'entité qui les a générés mais qui conviennent à tout le monde. Les plus paranoïaques peuvent craindre que les paramètres livrés avec leur logiciel soient détournés.
Afaict il n'y a pas de suites de chiffrement DHE qui utilisent RC4. Donc, dans votre configuration, cela n'aurait d'importance que si le client ne prend en charge aucune des suites de chiffrement que vous avez explicitement identifiées et finit par utiliser l'une des suites de chiffrement traditionnelles "DHE" de la liste "HIGH".
Je voudrais prendre en charge PFS (forward secrecy) s'il est pris en charge par le client.
Pour obtenir la confidentialité en avant, vous devez utiliser une suite de chiffrement DHE ou ECDHE, donc si la confidentialité en avant est votre priorité, vous devez les placer avant toutes les autres suites de chiffrement. Pour une compatibilité et des performances optimales, vous devez placer les suites de chiffrement ECHDE avant la suite de chiffrement DHE correspondante.
Enfin, réfléchissez bien avant de coder en dur les listes de chiffrement dans votre logiciel. Les options considérées comme les meilleures peuvent changer et changent avec le temps.
Les attaques de NSA sur RSA ont brouillé le PRNG (truc de nombre aléatoire). C'est un pari juste qui n'est pas le seul PRNG Voici un générateur aléatoire basé sur du matériel non américain qui mérite d'être étudié: http://www.entropykey.co.uk/