Just thought I'd share the tuned NginX configuration with you all here that is used on this (https-exclusive) forum.
A few non-standard things in place (because of my preference for Camellia over AES as a symmetric cypher) but that can always be changed if you want to prefer the use of Rijndael-based cyphers.

The first server {} block makes sure to redirect any http requests to https (not logging these redirections). Any errors are still logged to catch oddities/abuse/attacks.
Straight-forward and shouldn't be difficult to understand.

This is the preferred cypher order on this server, giving preference to Camellia with ephemeral Diffie-Hellman key exchange. Although this exchange is relatively expensive (It uses fixed parameters and not an elliptic curve), the lack of ECDHE for Camellia in common crypto libraries due to political decisions rather than technical ones enforces plain DHE for this. This is still safe because of a large key at the root of it (see dhparam). I'm a proponent of Camellia as a symmetric cypher because, unlike AES, there are no known weakening attacks against it and it's adopted as a strong cypher by several leading crypto authorities in the world. (Firefox users are out of luck because Mozilla has specifically disabled this cypher even if NSS supports it).
Beyond that, preferring Elliptic Curve and Galois-Counter modes for cypher suites, sorting them in most secure to least secure order gives a very secure end result (forward secrecy is used in all supported clients). Weak/broken cyphers like RC4, 3DES, MD5-based HMAC, Export and low sec suites are all disabled.

This is the pre-generated DHE parameter file using a 4096-bits RSA key. If you enable DHE-based cypher suites in your server, you should always generate these parameter files with sufficient size (at least 2048 bits) to prevent LOGJAM related weakness.
You can generate this with OpenSSL:openssl dhparam -out RSA4096.pem -5 4096

This enables and uses OCSP stapling, one of the chief mechanisms for quick and secure verification of the TLS certificates in use without having to call out to OCSP servers from the browser (increases client privacy and performance). We're using Cloudflare, HE and Google DNS servers for resolving, which should provide plenty of redundancy for the required server->OCSP connections.

This tunes miscellaneous headers to leverage client security features.
(If you want to know more about these headers, please inform yourself -- there are plenty of documents describing these features out on the web)

Result:

And all supported clients (everything except IE/XP and old java versions, pretty much) will use forward secrecy.
Cypher strength is not maxed out on purpose, because we want to strike a balance here to keep maximum accessibility while not compromising security.

I hope this is of use to anyone out there

Last edited by Moonchild on 2018-08-07, 01:55, edited 3 times in total.

Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

Very reasonable and secure setup indeed.
I always liked Camellia (because of a better name , and of course it has technical equivalence with AES), but wondered why there are fewer libraries and online resources in its support. Now I know why. Thank you!

Thanks for sharing! This is a good, general-purpose nginx config. I used to know almost all of these settings for apache, but I don't manage web server configs anymore. I was doing it during nginx's rise in popularity, so apache was my only choice. If I were to stand up a new web server, I'd try nginx and just copy this to start. Bookmark'd!