New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove deprecated ciphers and protocols #190
Conversation
TLSv1.0 & TLSv1.1 suffer from [POODLE](https://blog.qualys.com/ssllabs/2014/12/08/poodle-bites-tls) and other [padding oracle attack](https://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](https://www.digicert.com/blog/google-plans-to-deprecate-dhe-cipher-suites/) from any decent user agent and can lead to [mitm attack](https://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](https://sweet32.info/) So I recommend using only the `EECDH+CHACHA20:EECDH+AES` cipher suite, which has [quite good compatibility](https://cryptcheck.fr/suite/EECDH+CHACHA20:EECDH+AES) and a very better security than the actual cipher suite.
Using only a single cipher might be a bit overkill, but I do agree it can be updated. However, instead of updating it all the time, maybe it would be better to refer to for example Mozilla's recommended configurations instead to give freedom of choice to the user. |
I personaly disagree with the Mozilla recommended configuration. And in both cases, I disagree about the expanded cipher suite list, shortcut form like And my proposed cipher suite is not a single cipher, but 18 ciphers :
|
It's worth noting that PCI DSS will require websites to drop TLS 1.0 by 30 June 2018 https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls as well as requiring servers to be setup with secure cipher suites (though without specifically stating which they consider to be secure). From what I can see, |
@aeris Thanks for your PR! Could you update comments to reflect this change? Thanks! |
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 #201 Fix #183 Fix #190 Prepare #180 Co-authored-by: aeris <aeris@users.noreply.github.com>
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 #201 Fix #183 Fix #190 Prepare #180 Co-authored-by: aeris <aeris@users.noreply.github.com>
Hi! I'm trying to validate a site with a client specifications and I'm running into the issue that the report says CBC ciphers are still enabled, even though I'm using The thing is when I test the ciphers from the modern policy using
So my question is: is the current modern policy including these weak ciphers, and if not, then any ideas on why the report says they're enabled? I'm using the latest release of server-config-nginx and no interefing/invalid settings were found. |
@haggen If openssl doesn't list them then they are not included in the list by default.
|
TLSv1.0 & TLSv1.1 suffer from POODLE and other padding oracle attack
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 from any decent user agent and can lead to mitm attack (arround ~25min in the video) with only one side supporting weak cipher suite.
3DES is deprecated and suffer from sweet32
So I recommend using only the
EECDH+CHACHA20:EECDH+AES
cipher suite, which has quite good compatibility and a very better security than the actual cipher suite.