From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 19 11:17:53 2021 Received: (at 49035) by debbugs.gnu.org; 19 Jun 2021 15:17:53 +0000 Received: from localhost ([127.0.0.1]:60483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lucjI-0005zQ-NN for submit@debbugs.gnu.org; Sat, 19 Jun 2021 11:17:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lucjF-0005z9-MA for 49035@debbugs.gnu.org; Sat, 19 Jun 2021 11:17:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39478) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lucj8-0000mx-VW; Sat, 19 Jun 2021 11:17:42 -0400 Received: from deisui.org ([219.94.251.20]:60226 helo=localhost.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lucj8-0007O9-AG; Sat, 19 Jun 2021 11:17:42 -0400 Message-ID: <87tultyjcl.fsf-ueno@gnu.org> From: Daiki Ueno To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: [gnutls-help] TLS downgrade at bitbucket.org References: <871r93v665.fsf@inria.fr> <87pmwns3of.fsf@gnu.org> <87eed2re43.fsf_-_@gnu.org> Date: Sat, 19 Jun 2021 17:17:30 +0200 In-Reply-To: <87eed2re43.fsf_-_@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s?= =?utf-8?Q?=22's?= message of "Tue, 15 Jun 2021 23:51:08 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 49035 Cc: 49035@debbugs.gnu.org, Emmanuel Agullo , gnutls-help@lists.gnutls.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) Ludovic Court=C3=A8s writes: > $ gnutls-cli --priority=3D"NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VE= RS-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 =E2=80=9CDetected downgrade to TLS 1.2 from TLS 1.3= =E2=80=9D. > > 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=E2=80=99t 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, --=20 Daiki Ueno