Invalid cipher

[kevin25]

I used this cipher from the repo and it didn't work out.

ssl_protocols               TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ecdh_curve              X25519:P-256:P-384:P-224:P-521;
ssl_ciphers                 '[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES';
ssl_prefer_server_ciphers   on;

nginx: [emerg] SSL_CTX_set_cipher_list("[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES") failed (SSL: error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid command)
nginx: configuration file /etc/nginx/nginx.conf test failed

and

nginx: [emerg] SSL_CTX_set1_curves_list("X25519:P-256:P-384:P-224:P-521") failed (SSL:)

[franzhaenel]

If you're using Openssl 1.1.0g you need this patch: https://gitlab.com/buik/openssl/blob/openssl-patch/openssl-1.1/OpenSSL1.1g-equal-preference-cipher-groups.patch
I think it works for 1.1.0h as well. Also, TLS 1.3 is not available until OpenSSL 1.1.1 so you might want to omit the "TLSv1.3" part in ssl_protocols

[McKinleyGroup]

Hi @franzhaenel,
Hi @kevin25,

You should use OpenSSL 1.1.1 pre5:
https://www.openssl.org/source/openssl-1.1.1-pre5.tar.gz

and besides you should also skip TLS 1.0 and TLS 1.1:
Like this:

ssl_protocols TLSv1.2 TLSv1.3;

(DRAFT) NIST Special Publication 800-52, Revision 2
Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations
by Kerry McKay & David Cooper (page 8)

https://csrc.nist.gov/CSRC/media/Publications/sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf

---

That's the NIST recommendation for secure (government) sites. However, in the age of phishing, cyber attacks, ransomware,.... etc. you should keep your website as safe as possible. TLS 1.2 is good enough to cover legacies and TLS 1.3 is the way to go. With both you have both: backwards compatible & future-proof. :-)

I hope this helps... :-)

[injust]

I would recommend against migrating to OpenSSL 1.1.1, as it is currently an alpha-quality build for testing purposes only. It should not be used for security critical purposes.

Furthermore, TLS 1.2 is probably insufficient for legacy client support. The NIST guidelines are not applicable to all use cases, and you should always analyze your user base before deciding which protocols to support or drop.

@McKinleyGroup TLS protocol support also has nothing to do with phishing or ransomware, and a properly configured server, which should prefer stronger cipher suites and protocols over weaker ones, will have zero problems leaving TLS 1.0 and 1.1 enabled. They would only be used by legacy clients that do not support the modern protocols.

[McKinleyGroup]

Justin Su:

It's good enough for:
NIST and three-letter agencies,
Akamai,
Cloudflare,...

So, I don't see the point. TLS 1.2 is only a TEMPORARY legacy support...

TLS 1.0 has been hacked in 2011...
... so 7 years later you still want to hang on to it, why?

An open-door policy is important to you? :-)

Red alert: HTTPS has been hacked
There's now a tool that exploits a flaw in SSL and TLS. Will the industry respond fast enough?

https://www.infoworld.com/article/2620383/security/red-alert--https-has-been-hacked.html

Yahoo had 3 billion email accounts hacked and learned nothing from it:

https://www.ssllabs.com/ssltest/analyze.html?d=www.yahoo.com&s=2001%3a4998%3ac%3a1023%3a0%3a0%3a0%3a5&hideResults=on

TLS 1.3 is No
TLS 1.2 is Yes
TLS 1.1 is Yes
TLS 1.0 is Yes
SSL 3 is No
SSL 2 is No

---- a correct NIST-compliant configuration would be:

TLS 1.3 is Yes
TLS 1.2 is Yes
TLS 1.1 is No
TLS 1.0 is No
SSL 3 is No
SSL 2 is No

TLS protocol support also has nothing to do with phishing or ransomware

Keep dreaming... of course it has...

and a properly configured server,

like yahoo.com ??? :-)

TLS configuration isn't everything... cyber security headers should be done correctly...

https://securityheaders.com/?q=yahoo.com&followRedirects=on

Grade C:

• X-XSS-Protection,
• Content-Security-Policy,
• Referrer-Policy,

These three are missing and/or falsely configured... especially X-XSS-Protection is a must!!!

Quote by Securityheaders . io:

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block".
– It's not so difficult to this... :-(

and a properly configured server

Sounds nice... but according to IETF only:

• secure ciphers made it into TLS 1.3,
• some "secure" ciphers like CBC didn't because the "properly configured server" never materialized...

There is always a huge difference between theory in practice. In theory CBC could have been safe. However, in practice too many times CBC ciphers got hacked compromised!

For the IETF only practical results matter. I think this is a smart approach.

It's also stupid to claim that [a server] "will have zero problems leaving TLS 1.0 and 1.1 enabled"...
... that doesn't make sense after the hack in 2011... :-(
TLS 1.1 is very similar to TLS 1.0. That's why NIST dropped:

Not just SSL 2 and SSL3, but also TLS 1.0 and TLS 1.1! :-)

Makes perfectly sense to me!

[injust]

It's good enough for:
NIST and three-letter agencies,

There are numerous web-facing servers run by three-letter agencies that still support TLS 1.0 and 1.1. Take https://nsa.gov for instance.

Akamai

Not coincidentally, nsa.gov is also on Akamai, which, you guessed it, also supports < TLS 1.2.

Cloudflare

Not sure what your point is here, Cloudflare themselves support < TLS 1.2 everywhere. Hell, they even support SHA1 certificates for legacy legacy clients.

TLS 1.2 is only a TEMPORARY legacy support...

Yeah. Right.

TLS 1.0 has been hacked in 2011...
... so 7 years later you still want to hang on to it, why?

Because I, as well as most people in the industry, feel that legacy client support is, in a lot of cases, important. A significant portion of devices still do not support TLS 1.2 and AEAD cipher suites.

Keep dreaming... of course it has...

Give me one scenario, any practical scenario, where supporting TLS 1.1 would add additional risk to phishing or ransomware. I'll wait.

These three are missing and/or falsely configured... especially X-XSS-Protection is a must!!!

What does that have to do with TLS? Security in general is important, but headers are not relevant to this discussion.

It's also stupid to claim that [a server] "will have zero problems leaving TLS 1.0 and 1.1 enabled"...

Modern clients with proper TLS 1.2 implementations will only ever use TLS 1.2, even if the server supports legacy protocols. Sure, the protocols are weak, they're better than plain HTTP. Only clients that do not support TLS 1.2 would fall back to the legacy protocols and cipher suites, that is the entire point. If you feel comfortable dropping TLS 1.0 and 1.1 support, and forcing all of your legacy clients to HTTP instead, then go for it.

This is getting off topic, and further discussion would be best continued off this thread.