Au cours des deux dernières années, il y a eu un certain nombre de changements dans ce qui serait considéré comme une configuration optimale de la suite de chiffrement SSL (par exemple, les attaques BEAST et CRIME, les faiblesses de RC4)
Ma question est, ce qui serait actuellement considéré comme un ensemble optimal de suites de chiffrement SSL pour avoir permis avec les objectifs suivants.
La configuration la plus sécurisée ne dépend pas seulement des chiffres, mais aussi de la version tls utilisée. Pour openssl, tls 1.1/1.2 est préféré. BEAST et CRIME sont des attaques contre le client et sont généralement atténuées côté client, mais il existe également des atténuations côté serveur:
Pour une configuration parfaite: SSL a toujours un impact sur les performances à un niveau élevé, RC4 et d'autres suites de chiffrement rapides peuvent toujours convenir pour le contenu statique, en particulier. lorsqu'il est servi à partir de votre propre CDN.
Un bon guide pour comprendre OpenSSL est OpenSSL Cookbook avec des explications détaillées également sur PFS , cipher-suites, tls-version etc. pp .il y a 2 articles de blog qui expliquent PFS et la configuration pratique:
cipher-suites-suggestions pour activer PFS également sur les anciens clients:
# Apache
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
# nginx
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
Pour un manuel nginx/ssl détaillé, je voudrais vous diriger vers ceci Guide to Nginx + SSL + SPDY .
Au cours de l'année écoulée depuis la rédaction de cette réponse, le guide de Mozilla a été mis à jour régulièrement. Toutes mes réservations ci-dessous ont été prises en compte et je recommande le guide de tout cœur.
Je vous recommande de lire le guide TLS côté serveur de Mozilla . Il est complet et ils sont particulièrement attentifs à la compatibilité avec les anciens clients, parfois au détriment de la sécurité. (Après tout, IE 6 utilisateurs méritent de pouvoir télécharger Firefox.) Je voudrais souligner plusieurs choses:
La prise en charge Windows XP/IE 6 n'est pas optimale. Je vous suggère de le laisser tomber si possible. Il nécessite SSL 3.0, ce qui laisse les clients décents ouverts aux attaques de déclassement. Edit: Anti-faiblessepasswords rapporte dans les commentaires ci-dessus que IE 6 peut prendre en charge TLS 1.0. I Je n'ai aucune idée du pourcentage de IE 6 clients le supportent ou l'ont activé, cependant!
Soutenir XP/IE 8 n'est pas mauvais. Il prend en charge TLS 1.0, bien que sa meilleure suite de chiffrement soit DES-CBC3-SHA
et il ne prend pas en charge le parfait secret avancé ou SNI. (Ses deuxièmes meilleures suites de chiffrement sont RC4-SHA
et RC4-MD5
. 3DES est très lent, mais RC4 a des problèmes de sécurité. Évitez-le si possible.)
Les paramètres Diffie-Hellman de 2048 bits sont les meilleurs du point de vue de la sécurité, mais Java 6 ne prend en charge que les paramètres de 1024 bits. Les paramètres courants de 1024 bits peuvent ou non avoir été cassé par NSA supercomputers , mais DH 1024 bits est autrement plus ou moins sûr pour l'instant. Vous pourriez avoir besoin de l'utiliser. (Java 7 prend en charge ECDHE, en contournant tout le problème de DHE taille du paramètre.)
La liste principale des suites de chiffrement de Mozilla comprend RC4. Comme ci-dessus, je recommande la liste de la section RC4 faiblesse qui utilise à la place 3DES.
Les exemples de configuration de Mozilla activent SSL 3.0. Comme je l'ai dit, je découragerais cela.
Les exemples de configuration de Mozilla recommandent principalement des paramètres DH à 2048 bits, mais ils donnent également 1024 en option.
Bien sûr, la première étape consiste à maintenir OpenSSL (ou la bibliothèque que vous utilisez) à jour.
Mais à mesure que de nouvelles vulnérabilités sont découvertes et que les navigateurs sont mis à niveau, les réponses ici peuvent devenir obsolètes. Je vous suggère de vous fier au Générateur de configuration SSL Mozilla pour vérifier quelle configuration vous devez utiliser.
Le chiffrement SSL "optimal" que vous configurez sur votre serveur Web dépendra des besoins de vos clients. Dans de nombreux cas, cela serait un facteur dans le choix du protocole et des suites de chiffrement. Je ne sais pas si c'est le cas pour vous.
Vous pouvez configurer la meilleure sécurité possible - ne prend en charge que le protocole TLS 1.2, uniquement les chiffres avec Perfect Forward Security (PFS) et uniquement AES 256. Dans PFS, vous ne pouvez prendre en charge que la variante de courbe elliptique ECDHE. Vous pouvez choisir les nouveaux chiffrements GCM sécurisés qui fournissent un chiffrement authentifié et offrent de très bonnes performances (avec les instructions AES-NI). Mais si votre client le plus important utilise IE8 sur Windows 7 et que vous ne pouvez pas le convaincre de mettre à niveau le navigateur, il ne pourra pas utiliser votre service et vous perdrez un client.
ssllabs.com fournit un service Web pour analyser votre site et donner des notes comme A +, A, B, etc. La note est basée sur les scores numériques (max 100) reçus pour 4 paramètres --- Certificat, prise en charge de protocole, échange de clés et force de chiffrement . Ils donnent des notes plus élevées si Perfect Forward Secrecy (PFS), Strict Transport Security (HSTS), pour n'en nommer que quelques-uns, sont pris en charge.
Notez que le score peut changer sur une période de temps à mesure que les navigateurs et les serveurs sont corrigés, de nouvelles faiblesses apparaissent, de nouveaux exploits sont découverts, etc. mais ils ont ont cessé de le faire car ils considèrent que cela est atténué du côté client (sauf pour le Apple retardataire), mais plus encore parce que l'atténuation impliquait l'application de RC4 (pour les protocoles TLS 1.0 ou inférieur) et cela tourne que RC4 est beaucoup plus faible qu'on ne le pensait.
Vous pouvez aller sur le site ssl labs , entrez votre URL et obtenez le score.
Le rapport des laboratoires SSL comprend une section sur la simulation de prise de contact où il montre un tas de clients (navigateurs, Java, openssl) et quels protocoles, suites de chiffrement, tailles de clés seront négociés avec votre serveur. Si la négociation n'est pas possible, il affichera "Inadéquation du protocole ou de la suite de chiffrement" en rouge. Vous pouvez rechercher la simulation de prise de contact pour la configuration utilisée par vos clients importants. Par exemple, vous pouvez voir l'entrée
IE 8-10/Win7, TLS 1.0, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, FS 256
Mais supposons que vous resserriez la configuration SSL de votre serveur pour ne prendre en charge que TLS 1.2, cette ligne affichera
IE 8-10/Win7, Protocol or cipher suite mismatch, Fail
Mais, au fur et à mesure que vos clients migrent/mettent à jour/mettent à niveau, vous pouvez renforcer la sécurité dans le but de TLS 1.2 uniquement, PFS uniquement et 256 bits uniquement
Une autre information importante que le rapport fournit est de savoir si les suites de chiffrement sont dans l'ordre préféré du serveur ou non. Dans le premier cas, l'ordre de chiffrement répertorié dans la configuration du serveur sera respecté --- vous devez donc mettre les suites de chiffrement préférées en premier. Le premier chiffre de la liste que le serveur et le client peuvent utiliser sera choisi. Si vous utilisez Apache, vous pouvez l'activer avec la directive "SSLHonorCipherOrder on". Pour nginx, la directive est "ssl_prefer_server_ciphers on;"