Changes between Version 1 and Version 2 of Ticket #1901, comment 2


Ignore:
Timestamp:
12/13/19 04:29:38 (5 years ago)
Author:
jkman340@…

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1901, comment 2

    v1 v2  
    11Thanks 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.
    22
    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'.
     3Part 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'.