Ludovic Courtès <l...@gnu.org> writes: > $ gnutls-cli > --priority="NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2:+VERS-TLS1.3" > -p https bitbucket.org > Processed 444 CA certificate(s). > Resolving 'bitbucket.org:https'... > Connecting to '2406:da00:ff00::6b17:d1f5:443'... > |<1>| Detected downgrade to TLS 1.2 from TLS 1.3 > *** Fatal error: An illegal parameter has been received.
[...] > The key thing here is “Detected downgrade to TLS 1.2 from TLS 1.3”. > > Why is a downgrade detected when using the most explicit priority > string and not when using the shorter string? I would say this is an expected behavior when the TLS downgrade protection mechanism[1] is in action. What happens is as follows: - the client advertises TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 (in this order) in the supported_versions extension - the server skips TLS 1.0 and TLS 1.1 (maybe it's disabled), sees TLS 1.2 first in supported_versions, then TLS 1.3; while it also supports TLS 1.3, as TLS 1.2 has precedence and it selects TLS 1.2 and sends the downgrade sentinel in server_random - the client sees the sentinel while TLS 1.3 is enabled, treats it as an unwanted protocol downgrade > Aren’t these two priority strings supposed to be equivalent today? No. If -VERS-TLS-ALL is used, the default priorities on TLS versions in NORMAL are ignored; the user is responsible for building the priority string so it reflects the actual preference, which in this case is: -VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0 Footnotes: [1] https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3 Regards, -- Daiki Ueno
