Quels compromis de compatibilité devons-nous faire pour utiliser une configuration SSL durci pour Nginx?

J'ai trouvé certains parameters SSL durci dans github.com/ioerror/duraconf .

Voici l'en-tête de la configuration:

Ceci est un exemple de server proxy HTTPS SSLv3 et TLSv1 hautement sécurisé, quelque peu compatible. Le server ne permet que les modes qui offrent un secret vers l'avant parfait; aucun autre mode n'est offert. Les modes de chiffrement anonymes sont désactivés. Cette configuration ne comprend pas l'en-tête HSTS pour s'assurer que les users ne se connectent pas accidentellement à un service HTTP non sécurisé après leur première visite.

Il prend uniquement en charge les numbers élevés en mode PFS:

ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # Only strong ciphers in PFS mode ssl_ciphers ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA; ssl_protocols SSLv3 TLSv1; 

Si nous devions utiliser ces parameters sur notre site Web, qu'est-ce que "un peu compatible" signifie? Par exemple, IE6 serait-il encore capable de se connecter?

Internet Explorer sur Windows XP (c'est 6, 7 et 8) ne peut pas se connecter car ils ne prennent pas en charge Forward Privacy. Vous pouvez tester des choses comme celle-ci sur votre propre à SSLLabs .

À part ça, tout devrait fonctionner, mais il pourrait y avoir de vieux clients mobiles qui ne peuvent pas se connecter aussi. Cela nécessiterait d'autres tests.


Personnellement, je pense que cette configuration n'est pas adaptée aux sites Web du monde réel. AES256 est un simulateur et ne fait qu'accroître le time de connection. AES128 est plus que suffisant pour les sites Web normaux , regardez ce document auprès de Seagate . Sauf si vous envisagez de déployer un site Web bancaire ou peut-être un coup de sifflet, allez avec AES128 et épargnez votre server des frais généraux informatiques.

Ma configuration personnelle pour nginx ressemble à la suivante (la configuration nginx complète peut être trouvée dans l'un de mes repositorys ).

 # Content Security Policy # # LINK: http://www.w3.org/TR/CSP/ add_header X-WebKit-CSP "default-src 'self' *.example.com;"; add_header X-Content-Security-Policy "default-src 'self' *.example.com;"; add_header Content-Security-Policy "default-src 'self' *.example.com;"; # Do not allow embeding of our website in iframes. # # LINK: http://tools.ietf.org/html/rfc7034 # LINK: http://tools.ietf.org/html/draft-ietf-websec-frame-options-00 add_header X-Frame-Options "DENY"; add_header Frame-Options "DENY"; # Only communicate view encrypted connections on all domains, forever! # # LINK: https://tools.ietf.org/html/rfc6797 add_header Ssortingct-Transport-Security "max-age=262974383; includeSubdomains;"; # (Re)Enable web browser XSS filter protection (IE+Chrome). # # LINK: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx add_header X-XSS-Protection "1; mode=block"; # Use a public DNS to resolve OCSP responder hostnames. The answer stays valid for a complete day. # # LINK: http://pcsupport.about.com/od/tipssortingcks/a/free-public-dns-servers.htm resolver 209.244.0.3 209.244.0.4 valid=86400; # We only support AES128 and Elliptic curve Diffie–Hellman (ECDH) plus Diffie–Hellman (DH) in order to enable Forward # Secrecy. This configuration ensures highest compatibility, best performance while still being extremely secure. Please # note that using AES128 isn't really less secure than any other AES implementation. # # LINK: http://www.scribd.com/doc/29872766/128-Bit-vs-256-Bit-AES-Encryption ssl_ciphers "EECDH+AESGCM EDH+AESGCM EECDH -RC4 EDH -CAMELLIA -SEED !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !AES256"; ssl_ecdh_curve secp384r1; # Prefer our configured ciphers over the client specified ones. ssl_prefer_server_ciphers on; # Only support newest protocols, unfortunately we have to support TLS 1.0 and 1.1, otherwise 99% of the internet can't # connect to our server. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Use a shared (among all nginx worker threads) cache for SSL sessions; one megabyte can store about 4000 sessions. # # LINK: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache ssl_session_cache shared:SSL:100m; # Number of seconds before an SSL session expires in the session cache. Should match the keepalive value. # # LINK: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout # LINK: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslsessioncachetimeout ssl_session_timeout 60; # Enable OCSP stapling. # # LINK: http://tools.ietf.org/html/rfc4366#section-3.6 # LINK: http://tools.ietf.org/html/rfc6066 ssl_stapling on; ssl_stapling_verify on; # The certificatee of our authority for OCSP verification. ssl_trusted_certificatee ssl/ca-bundle.pem; 

J'utilise également un script init.d personnalisé pour démarrer nginx et récupérer directement la réponse OSCP, ce qui garantit que tous les clients peuvent le valider. Vous pouvez le find dans l'un de mes repositorys .

Qu'entendez-vous par "endurci" dans le cas de SSL?

Quelles sont les cipher_suites utilisées d'abord dépend de ce que cipher_suites est disponible sur votre server, puis sur server_suggestions, puis sur ce que le client peut parler. Avec ces cipher_suites, vous avez configuré ECDHE et DHE qui est plutôt correct lorsque vous souhaitez utiliser PFS, mais comme seul TLSv1 est activé, je ne pense pas pouvoir utiliser ECDHE de toute façon, de sorte que vous vous enverrez à DHE, qui pourrait être utilisé avec la plupart les browsers. Certains clients très hérités (IIRC IE <= 9) pourraient ne pas pouvoir utiliser PFS, donc vous les garderez avec cette configuration.

Si vous voulez passer au browser, vérifiez les cipher_suites:

  • configurez votre nginx pour les utiliser
  • vérifiez les numbers sur ssllabs.com
  • vous pouvez vérifier quels numbers sont disponibles sur votre server avec les openssl ciphers

le problème avec la prise de cipher_suggestions de tiers:

  • Si votre server ne parle pas tlsv1.2, vous ne pourrez pas utiliser les sets de chiffrement PFS modernes comme tous ces codes ECDHE, mais utiliseront les parameters DHE très lents
  • vous devriez voir et ssllabs-vérifier vos suites de chiffrage toujours pour voir quels browsers peuvent avoir des problèmes.

vous findez plus d'infos sur nginx + ssl ici: Guide de Nginx + SSL + SPDY


certaines choses auxquelles je n'aime pas le nginx-config que vous avez lié à:

  • le cache cache également "hickups" en amont
  • le ssl-config n'est pas vraiment le meilleur et sûrement pas de haute security

~~~

 ssl_protocols SSLv3 TLSv1; # -> no tlsv1.2/tlsv1.2??? this is NOT high security # as mentioned in the header proxy_cache_valid any 1h; # REALLY??? 

~~~

Ma meilleure estimation est que «quelque chose de compatible» est utilisé comme moyen de dire «pas entièrement compatible».

Cette list de chiffrage ne supporte pas IE6 car IE6 n'a pas de chiffrages FPS disponibles.

Vous pouvez également find cet article d'utilisation.