prime256v1 (NIST P-256), secp384r1 (NIST P-384) and secp521r1 (NIST P-521) have been deemed insecure as per Daniel J. Bernstein's research (https://cr.yp.to/newelliptic/nistecc-20160106.pdf, https://safecurves.cr.yp.to/).
Despite that, the adoption of X25519 is too slim. Limiting to that curve would mean dropping compatibility with Safari, Edge and Internet Explorer.
prime256v1 (NIST P-256), secp384r1 (NIST P-384) and secp521r1 (NIST P-521) have been deemed insecure as per Daniel J. Bernstein's research (https://cr.yp.to/newelliptic/nistecc-20160106.pdf, https://safecurves.cr.yp.to/).
Despite that, the adoption of X25519 is too slim. Limiting to that curve would mean dropping compatibility with Safari, Edge and Internet Explorer.
TLSv1.0 & TLSv1.1 suffer from [POODLE](blog.qualys.com/ssllabs/2014/12/08/poodle-bites-tls) and other [padding oracle attack](blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites)
You need to support only TLSv1.2 to expect closing those weakness (and use only AEAD cipher suite in case of padding oracle).
The same, non PFS cipher suite is not at all recommended (see heartbleed effect).
DHE support [is dropped](digicert.com/blog/google-plans-to-deprecate-dhe-cipher-suites) from any decent user agent and can lead to [mitm attack](media.ccc.de/v/32c3-7288-logjam_diffie-hellman_discrete_logs_the_nsa_and_you#t=1357) (arround ~25min in the video) with only one side supporting weak cipher suite.
3DES is deprecated and suffer from [sweet32](sweet32.info)
So I recommend using only the `EECDH+CHACHA20:EECDH+AES` cipher suite, which has [quite good compatibility](cryptcheck.fr/suite/EECDH+CHACHA20:EECDH+AES) and a very better security than the actual cipher suite.
Fix#201Fix#183Fix#190
Prepare #180
Co-authored-by: aeris <aeris@users.noreply.github.com>
No need to add a semicolon for the last directive. In addition, having that unnecessary semicolon causes the HSTS tool (https://hstspreload.org/) for getting on the preload list to fail with an error about the semicolon.
A previous commit removed some, but missed these. Where a location
directive was using Expires to set a future expiry in conjunction
with Cache-Control public, I have replaced the time with an equal
max-age.
Furthermore, Google's web performance guide says that "public" is
implicit if there is a max-age specified.
See: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
From nginx' add_header documentation:
```
add_header Adds the specified field to a response header provided that
the response code equals 200, 201, 204, 206, 301, 302, 303, 304, or 307.
```
At least for all security-relevant headers this should not be the case
and the header should always be added.
Ewout van Mansom