First, let's go over how cipher suite negotiation works, very briefly. For example, we can use the TLS 1.2 document RFC 5246 starting at section 7.4.1.2 to see, in the short short form:

• ClientHello: The client tells the server which cipher suites the client supports
• Now the server picks one
  • I'll discuss how to control which one it picks next!
• ServerHello: The server tells the client which cipher suite it has chosen, or gives the client a failure message.

Now, as to the actual selection. I've used the nginx ssl module documentation, the Qualys 2013 article on Configuring Apache, Nginx, and OpenSSL for Forward Secrecy, and the Hynek Hardening Your Web Server’s SSL Ciphers article for reference. The latter two cover both Apache and Nginx (as both use OpenSSL as a base).

Essentially, you need to tell Nginx to use the order you select, and you need to select an order. To see what the results of that order would be, you can use the OpenSSL command line, e.g.

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'

NOTE: You may want to remove :!3DES from that string; 3-key triple-DES isn't efficient, but it is still secure in and of itself to more or less 112 bits of security, and is very, very common.

Use the above command to determine which cipher suites will be most preferred and least preferred in your configuration, and change it until you like the results. The references I've given have their own strings; I amended it slightly to get the above example (removing RC4 and SEED, and putting every TLS 1.2 cipher suite above any 'SSLv3' cipher suite, for example).

Then, for Nginx in particular, you would alter your configuration file to include something like:

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";

Add in SSLv3 to ssl_protocols if you really insist on it.

The ssl_prefer_server_ciphers will inform nginx to use the order we specify, and ignore the order the client presents their cipher list in. Now, if the only shared cipher suite between the ClientHello and the list OpenSSL ciphers -v ... gives is our least preferred cipher, that's of course what nginx will use. If nothing matches, then we send the client a failure notice.

The ssl_ciphers command is the meat of the choice, here, as nginx will inform OpenSSL of our preferred cipher suite list. Please, please use the openssl ciphers -v command to see the results you get on your platform. Ideally, check it again after changing OpenSSL versions.

Also, please read Scott Helme's article on Setting up HSTS (HTTP Strict Transport Security) in nginx, which will allows a host to enforce the use of HTTPS on the client side. Be sure to include the HSTS header inside the http block with the ssl listen statement.

Edited to add: At least after this (if not before also), go to Qualys SSL Labs to see HTTPS security information and to Test Your Server that's been kept pretty well up to date for the last few years. Recommendations change regularly, and sometimes even frequently reverse themselves (RC4, for example, what nearly whiplash inducing). You can also even Test Your Browser!

Mozilla verfügt über ein Online-Tool, mit dem Sie die richtige Verschlüsselungssuite auswählen können.

https://mozilla.github.io/server-side-tls/ssl-config-generator/

Damit können Sie Ihren Server eingeben Version, Softwareversion usw. und wählen Sie dann zwischen einem Gleichgewicht zwischen Sicherheit und Legacy-Unterstützung.

OpenSSL bevorzugt natürlich neuere MACs für ansonsten äquivalente Cipher Suites. Beispielsweise beginnt die lange Ausgabe von openssl chiphers -v für Ihre Verschlüsselungszeichenfolge mit:

  ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx = ECDH Au = RSA Enc = AESGCM (256) Mac = AEADECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx = ECDH Au = ECDSA Enc = AESGCM (256) Mac = AEADECDHE-RSA-AES256-SHA384 TLSv1.2 Kx = ECD = RSA Enc = AES (256) Mac = SHA384ECDHE-ECDSA-AES256-SHA384 TLSv1,2 Kx = ECDH Au = ECDSA Enc = AES (256) Mac = SHA384ECDHE-RSA-AES256-SHA SSLv3 Kx = ECDH Au = RSA Enc = AES (256) Mac = SHA1ECDHE-ECDSA-AES256-SHA SSLv3 Kx = ECDH Au = ECDSA Enc = AES (256) Mac = SHA1  

Natürlich verwendet TLS nur unterstützte Verschlüsselungssuiten sowohl vom Server als auch vom Client gegenseitig, und weder Chrome noch Firefox unterstützen HMAC-SHA256-Verschlüsselungssuiten. Da HMAC-SHA1 (und sogar HMAC-MD5) immer noch als sicher gelten, sind ihre Entwickler (und die von NSS, der TLS-Bibliothek, die beide verwenden) skeptisch, Entwickleraufwand und TLS-Handshake-Größe zu verschwenden, indem sie neue, unnötige und rückwärts gerichtete hinzufügen -inkompatible Cipher Suites.

Sehen Sie sich beispielsweise die von Chrome 33 unterstützten Cipher Suites in der Reihenfolge ihrer Präferenz an:

1. ChaCha20- Poly1305,
2. AES-128-GCM,
3. AES-256-CBC mit HMAC-SHA1,
4. RC4 (ugh) und AES- 128-CBC mit HMAC-SHA1, ...
ol>

OpenSSL unterstützt ChaCha20-Poly1305 nicht. Wenn Ihr AES-GCM ebenfalls nicht unterstützt (???) und ein RSA-Zertifikat verwendet, ist ECDHE-RSA-AES256-SHA natürlich die von Chrome verwendete Verschlüsselungssuite. (Firefox 29 würde ECDHE-RSA-AES128-SHA verwenden.)

(Die "SHA-256" -Verschlüsselungssuiten, die Sie auf anderen Websites verwendet haben, sind vermutlich ChaCha20- Poly1305 oder AES-128-GCM, bei denen es sich um AEADs handelt, die kein HMAC verwenden, deren Chiffresuiten jedoch SHA-256 im PRF verwenden.)

for best compatibility the cloudflare-cipher-suite is not the best; i found the following better:

# 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;

when you check each setup with ssllabs you'll find for those 2 suites the following statement:

• Forward Secrecy Yes (with most browsers) ROBUST

while on your suggested cipher_suite it says:

• Forward Secrecy Yes (with modern browsers)

additional information: Guide to Nginx + SSL + SPDY

Comodo-Empfehlung lautet:

  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: HOCH :! ANULL :! ENULL :! EXPORT :! DES :! MD5 :! PSK :! RC4 " ;  

Quelle: https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/789/37/

https://cipherli.st/ ist eine weitere Site, die Folgendes bietet:

Die oben genannten Chiffren können in Ihrer Nginx-, Lighttpd- oder Apache-Konfiguration kopiert werden. Diese bieten eine starke SSL-Sicherheit für alle modernen Browser, und Sie erhalten ein A + für den SSL Labs-Test.

Dieses Zeug ist im Mai immer veraltet, aber für das, was es wert ist 2018 sind hier die Empfehlungen für nginx:

  ssl_protocols TLSv1.3; # Benötigt nginx > = 1.13.0, andernfalls verwenden Sie TLSv1.2ssl_prefer_server_ciphers on; ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512: DHE-RSA-AES256-GCM-SHA512: ECDHE-RSA-AES256-GCM-SHA384: DHE-RSA-A25 GCM-SHA384: ECDHE-RSA-AES256-SHA384; ssl_ecdh_curve secp384r1; # Benötigt nginx > = 1.1.0ssl_session_timeout 10m; ssl_session_cache shared: SSL: 10m; ssl_session_tickets off; # Benötigt nginx > = 1.5.9ssl_stapling on; # Benötigt nginx > = 1.3.7ssl_stapling_verify on; # Benötigt nginx = > 1.3.7  

Choice of hash function (SHA-1 vs SHA-256) does not really depend on the cipher suite, but on the protocol version. Basically, you get SHA-256 if you use TLS 1.2, SHA-1 if you use an older version.

(Yes, I known this is a simplified description of a slightly more complex situation, but here it works.)

Normally, client and server will use the highest protocol version that they both support, so you should already get TLS-1.2 (hence SHA-256) whenever it is possible. Note that this requires that both the server's code (OpenSSL) and the client's code are recent. You can alter that mechanism explicitly with ssl_protocols.