Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (7 lines)
> $ 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.
[...]
Toggle quote (5 lines)
> 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 downgradeprotection 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
Toggle quote (2 lines)
> Aren’t these two priority strings supposed to be equivalent today?
No. If -VERS-TLS-ALL is used, the default priorities on TLS versions inNORMAL are ignored; the user is responsible for building the prioritystring 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.0Footnotes:[1] https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3Regards,-- Daiki Ueno