bug#49035: [gnutls-help] TLS downgrade at bitbucket.org

[Daiki Ueno <ueno@gnu.org>]

Ludovic Courtès <ludo@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