4 ms·

The cipher list is effectively a big issue. When using the good old Sun Fortran compiler, I was used to have a -fast flag which would be smart to detect the har

by Loic 11y ago

The cipher list is effectively a big issue. When using the good old Sun Fortran compiler, I was used to have a -fast flag which would be smart to detect the hardware and be as fast as possible while respecting the IEEE maths (as far as I can remember). I would love a -secure flag to just use the most secure option of the current version of the software even at the cost of X years of backward compatibility at the tool/client/browser level. For example for nginx instead of something like: ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS; You would get: ssl_ciphers SECURE;

cm2187 11y ago
Or they should package it in vestions. "TLS 1.3" would come with a standard list of ciphers and other parameters. All you would have to do is tell your system "Disable SSL3.0" "Enable TLS 1.3", etc. Right now it feels like trying to fly a B747.
- brians 11y ago
  That does happen! Enable TLS 1.2 only and you're in pretty good shape. TLS 1.3 will drop more bad stuff and add a bit more good stuff.
  - stealthyb 11y ago
    It definitely helps, but if you're trying to keep up with the latest security, you'd be susceptible to Logjam (due to DHE-supporting ciphers in the default TLS 1.2 list). There's the Mozilla SSL Configuration Generator which helps with the madness, but they still aren't keeping up with the latest recommendations.
nailer 11y ago
> I would love a -secure flag to just use the most secure option of the current version of the software even at the cost of X years of backward compatibility at the tool/client/browser level. > ssl_ciphers SECURE; That's actually pretty close to nginx's default (unpatched) config (http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_c...), except openssl calls it HIGH. ssl_ciphers HIGH:!aNULL:!MD5; How high HIGH is depends on your version of openssl, ie, you probably don't want it for, say RHEL 5's openssl. Which (openssl has a long lifecycle, LTS Linux distros extend it further) some places may still be using. https://www.openssl.org/docs/manmaster/apps/ciphers.html https://www.openssl.org/docs/manmaster/apps/ciphers.html A better implementation of the same concept is Mozilla's SSL Config Generator (which is what CertSimple point customers to - we also maintain the node port): it has Modern/Intermediate/Old with a clear idea of the compatibility you're losing with each: https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat...

by Loic 11y ago

cm2187 11y ago

Or they should package it in vestions. "TLS 1.3" would come with a standard list of ciphers and other parameters. All you would have to do is tell your system "Disable SSL3.0" "Enable TLS 1.3", etc. Right now it feels like trying to fly a B747.

brians 11y ago
That does happen! Enable TLS 1.2 only and you're in pretty good shape. TLS 1.3 will drop more bad stuff and add a bit more good stuff.
- stealthyb 11y ago
  It definitely helps, but if you're trying to keep up with the latest security, you'd be susceptible to Logjam (due to DHE-supporting ciphers in the default TLS 1.2 list). There's the Mozilla SSL Configuration Generator which helps with the madness, but they still aren't keeping up with the latest recommendations.

nailer 11y ago

> I would love a -secure flag to just use the most secure option of the current version of the software even at the cost of X years of backward compatibility at the tool/client/browser level. > ssl_ciphers SECURE; That's actually pretty close to nginx's default (unpatched) config (http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_c...), except openssl calls it HIGH. ssl_ciphers HIGH:!aNULL:!MD5; How high HIGH is depends on your version of openssl, ie, you probably don't want it for, say RHEL 5's openssl. Which (openssl has a long lifecycle, LTS Linux distros extend it further) some places may still be using. https://www.openssl.org/docs/manmaster/apps/ciphers.html https://www.openssl.org/docs/manmaster/apps/ciphers.html A better implementation of the same concept is Mozilla's SSL Config Generator (which is what CertSimple point customers to - we also maintain the node port): it has Modern/Intermediate/Old with a clear idea of the compatibility you're losing with each: https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat...