Ssl_ciphers recommandés pour la sécurité, la compatibilité - Perfect Forward secret
J'utilise actuellement nginx avec les chiffres suivants:
ssl_ciphers HIGH:!aNULL:!eNULL:!LOW:!ADH:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;
Je souhaite conserver la compatibilité avec les anciens navigateurs, en particulier les anciens navigateurs mobiles et donc ne pas interdire complètement SHA1.
Comment puis-je obtenir que SHA256 soit préféré à SHA1 pour MAC (Message Authentication Code) et toujours utilisé lorsque cela est possible.
Je peux par exemple forcer l'application de SHA256 en ajoutant SHA256:! SHA: à ma chaîne ssl_ciphers, mais cela interdirait également complètement SHA1.
Avec ssl_cipher au début, il a cependant tendance à n'utiliser que SHA1. Des recommandations?
Mise à jour 29.12.2014
Merci à tous pour les contributions constructives et la discussion.
Même si je pense toujours que la page Mozilla côté serveur TLS couvre globalement le sujet assez bien - je ne recommanderais que la compatibilité moderne avec la limitation que la DSS doivent être supprimés de celui-ci et explicitement interdits (! DSS) comme recommandé dans le commentaire d'Anti-faibles mots de passe - merci de l'avoir repéré.
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DSS:!DES:!RC4:!3DES:!MD5:!PSK
Fait intéressant, ssllabs n'a pas alerté ou baissé le taux pour cela ...
De plus, je préfère utiliser des paramètres diffie hellman générés sur mesure. Même si les standards sont évidemment considérés comme sûrs. Quels sont les paramètres standard d'OpenSSL Diffie Hellmann (nombres premiers)?
openssl dhparam -check -out /etc/ssl/private/dhparams.pem 2048
augmentez cela à 4096 pour la paranoïa et le plaisir si vous le souhaitez.
Tout d'abord, passons brièvement en revue le fonctionnement de la négociation de la suite de chiffrement. Par exemple, nous pouvons utiliser le document TLS 1.2 RFC 5246 à partir de la section 7.4.1.2 pour voir, sous la forme abrégée courte:
- ClientHello: le client indique au serveur les suites de chiffrement prises en charge par le client
- Maintenant, le serveur en choisit un
- Je vais discuter de la façon de contrôler celui qu'il choisit ensuite!
- ServerHello: le serveur indique au client la suite de chiffrement qu'il a choisie ou donne au client un message d'échec.
Maintenant, quant à la sélection réelle. J'ai utilisé le documentation du module ssl nginx , le article Qualys 2013 sur la configuration d'Apache, Nginx et OpenSSL pour le secret à terme , et le Hynek Hardening Your Web Chiffres SSL du serveur article pour référence. Les deux derniers couvrent à la fois Apache et Nginx (car les deux utilisent OpenSSL comme base).
Essentiellement, vous devez dire à Nginx d'utiliser la commande que vous sélectionnez et vous devez sélectionner une commande. Pour voir quels seraient les résultats de cet ordre, vous pouvez utiliser la ligne de commande OpenSSL, par ex.
openssl ciphers -v 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED'
REMARQUE: vous souhaiterez peut-être supprimer:! 3DES de cette chaîne; Le triple DES à trois clés n'est pas efficace, mais il est toujours sécurisé en soi à plus ou moins 112 bits de sécurité, et est très, très courant.
Utilisez la commande ci-dessus pour déterminer quelles suites de chiffrement seront les plus préférées et les moins préférées dans votre configuration, et modifiez-la jusqu'à ce que les résultats vous plaisent. Les références que j'ai données ont leurs propres chaînes; Je l'ai légèrement modifié pour obtenir l'exemple ci-dessus (en supprimant RC4 et SEED, et en plaçant chaque suite de chiffrement TLS 1.2 au-dessus de toute suite de chiffrement 'SSLv3', par exemple).
Ensuite, pour Nginx en particulier, vous devez modifier votre fichier de configuration pour inclure quelque chose comme:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED";
Ajoutez SSLv3 à ssl_protocols si vous insistez vraiment dessus.
Les ssl_prefer_server_ciphers informeront nginx d'utiliser l'ordre que nous spécifions et ignoreront l'ordre dans lequel le client présente leur liste de chiffrement. Maintenant, si la seule suite de chiffrement partagée entre ClientHello et la liste qu'OpenSSL ciphers -v ... donne est notre moins préférée chiffre, c'est bien sûr ce que nginx utilisera. Si rien ne correspond, nous envoyons au client un avis d'échec.
La commande ssl_ciphers est la viande du choix, ici, car nginx informera OpenSSL de notre liste de suites de chiffrement préférée. Veuillez utiliser la commande openssl ciphers -v pour voir les résultats que vous obtenez sur votre plate-forme. Idéalement, vérifiez-le à nouveau après avoir changé les versions d'OpenSSL.
Lisez également article de Scott Helme sur la configuration de HSTS (HTTP Strict Transport Security) dans nginx , qui permettra à un hôte d'appliquer l'application de HTTPS du côté client. Assurez-vous d'inclure l'en-tête HSTS dans le bloc http avec l'instruction d'écoute ssl.
Modifié pour ajouter: au moins après cela (sinon avant également), accédez à Qualys SSL Labs pour voir les informations de sécurité HTTPS et à Testez votre serveur qui a été conservé assez bien à ce jour au cours des dernières années. Les recommandations changent régulièrement et parfois même se renversent souvent (RC4, par exemple, ce qui provoque presque un coup de fouet cervical). Vous pouvez également même Testez votre navigateur !
Mozilla dispose d'un outil en ligne qui vous aidera à choisir la bonne suite de chiffrement.
https://mozilla.github.io/server-side-tls/ssl-config-generator/
Il vous permettra de saisir la version de votre serveur, la version du logiciel, etc., puis de choisir entre un équilibre entre la sécurité et le support hérité.
pour une meilleure compatibilité, la suite de chiffrement cloudflare n'est pas la meilleure; j'ai trouvé mieux ce qui suit:
# suggestion from sslabs / including PFS, good compatibility
#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;
# suggestion my mozilla-server-team - good compatibility, pfs
#ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;
lorsque vous vérifiez chaque configuration avec ssllabs vous trouverez pour ces 2 suites la déclaration suivante:
- Secret de transmission Oui (avec la plupart des navigateurs) ROBUSTE
tandis que sur votre suggestion de chiffrement, il est dit:
- Forward Secrecy Oui (avec les navigateurs modernes)
informations supplémentaires: Guide de Nginx + SSL + SPDY
OpenSSL préférera naturellement les MAC plus récents pour les suites de chiffrement autrement équivalentes . Par exemple, le long openssl ciphers -v la sortie de votre chaîne de chiffrement commence par:
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
Bien sûr, TLS n'utilisera que des suites de chiffrement prises en charge mutuellement par le serveur et le client, et ni Chrome ni Firefox ne prennent en charge les suites de chiffrement HMAC-SHA256. Depuis HMAC-SHA1 (et même HMAC-MD5) sont toujours considérés comme sécurisés, je pense que leurs développeurs (et ceux de NSS, la bibliothèque TLS qu'ils utilisent tous les deux) sont sceptiques quant au gaspillage des efforts des développeurs et de la taille de la négociation TLS en ajoutant de nouvelles suites de chiffrement inutiles et incompatibles en arrière.
Regardez, par exemple, les suites de chiffrement prises en charge par Chrome 33 par ordre de préférence :
- ChaCha20-Poly1305 ,
- AES-128-GCM,
- AES-256-CBC avec HMAC-SHA1,
- RC4 (ugh) et AES-128-CBC avec HMAC-SHA1, ...
OpenSSL ne prend pas en charge ChaCha20-Poly1305. Si le vôtre ne prend pas en charge AES-GCM non plus (???) et utilise un certificat RSA, ECDHE-RSA-AES256-SHA est naturellement la suite de chiffrement Chrome utilisera. (Firefox 29 utiliserait ECDHE-RSA-AES128-SHA.)
(Les suites de chiffrement "SHA-256" que vous avez vues être utilisées sur d'autres sites Web sont probablement ChaCha20-Poly1305 ou AES-128-GCM, qui sont AEADs qui n'utilisent pas HMAC, mais dont les suites de chiffrement utilisent SHA-256 dans le PRF .)
https://cipherli.st/ est un autre site qui propose:
Les chiffres ci-dessus sont copiables et collables dans votre configuration nginx, Lighttpd ou Apache. Ceux-ci offrent une sécurité SSL renforcée pour tous les navigateurs modernes, et vous obtenez un A + au test SSL Labs.
Ce truc est obsolète tout le temps, mais pour ce qu'il vaut, en mai 2018, voici ses recommandations pour nginx:
ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
La recommandation de Comodo est:
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
Source: https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/789/37/
Le choix de la fonction de hachage (SHA-1 vs SHA-256) ne dépend pas vraiment de la suite de chiffrement , mais de la version du protocole . Fondamentalement, vous obtenez SHA-256 si vous utilisez TLS 1.2 , SHA-1 si vous utilisez une ancienne version.
(Oui, je savais qu'il s'agit d'une description simplifiée d'une situation légèrement plus complexe, mais ici cela fonctionne.)
Normalement, le client et le serveur utiliseront la version de protocole la plus élevée qu'ils prennent tous les deux en charge, vous devriez donc déjà obtenir TLS-1.2 (d'où SHA-256) chaque fois que cela est possible. Notez que cela nécessite que le code du serveur (OpenSSL) et le code du client soient récents. Vous pouvez modifier ce mécanisme explicitement avec ssl_protocols .