Changes between Version 1 and Version 2 of Ticket #1901, comment 2
- Timestamp:
- 12/13/19 04:29:38 (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1901, comment 2
v1 v2 1 1 Thanks for the reply and pointing to #1529. After reading #1529 I see what you mean. I echo the one user's comments that the Nginx documentation should be updated to reflect that the 'ssl_ciphers' directive only applies to TLSv1.2 and earlier and TLSv1.3 ciphers are enabled by default. 2 2 3 Part of the issue too was I was running 'openssl ciphers TLSv1.3' on an Ubuntu Bionic system that was using OpenSSL v1.1.1, which does in fact return a valid list of TLSv1.3 ciphers. On this version you could also run 'openssl ciphers gibberish' and it would return the same result. Even though 'gibberish' is not a valid cipher string, the TLSv1.3 ciphers are always returned. This behavior changed in openssl 1.1.1b (https://github.com/openssl/openssl/pull/7759). Now running 'openssl ciphers TLSv1.3' or 'openssl ciphers jibberish' now returns the error as seen above of 'no cipher match'.3 Part of the issue too was I was running 'openssl ciphers TLSv1.3' on an Ubuntu Bionic system that was using OpenSSL v1.1.1, which does in fact return a valid list of TLSv1.3 ciphers. On this version you could also run 'openssl ciphers gibberish' and it would return the same result. Even though 'gibberish' is not a valid cipher string, the TLSv1.3 ciphers are always returned. This behavior changed in openssl 1.1.1b (https://github.com/openssl/openssl/pull/7759). On v1.1.1.b or later, now running 'openssl ciphers TLSv1.3' or 'openssl ciphers jibberish' now returns the error as seen above of 'no cipher match'.