[TLS] Malformed Finished handling
Hubert Kario <hkario@redhat.com> Wed, 04 July 2018 09:54 UTC
Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F88C130E40 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 02:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKRjXPhv7zxD for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 02:54:20 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3343A130E17 for <tls@ietf.org>; Wed, 4 Jul 2018 02:54:20 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4AA28401C7E9 for <tls@ietf.org>; Wed, 4 Jul 2018 09:54:19 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 069E9111AF00 for <tls@ietf.org>; Wed, 4 Jul 2018 09:54:18 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 04 Jul 2018 11:54:17 +0200
Message-ID: <2069745.MLjj786GGa@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart5610978.he5WgMdfr5"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 04 Jul 2018 09:54:19 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 04 Jul 2018 09:54:19 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2VVyEYobJFObzFjgSX0t3IWAuwc>
Subject: [TLS] Malformed Finished handling
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2018 09:54:23 -0000
Despite this, is it correct to terminate a connection with "illegal_parameter" upon receiving a Finished handshake message with a 100 byte payload? or a 20 byte payload? My opinion is that it is not, "decode_error" is more specific so it should be used instead. Specification says the following on the matter: The draft 28 specifies the Finished message as having following structure: struct { opaque verify_data[Hash.length]; } Finished; At multiple places it also talks about handling messages that have sizes that don't match their structure as requiring termination of connection with "decode_error". The generic situation in Section 6: Peers which receive a message which cannot be parsed according to the syntax (e.g., have a length extending beyond the message boundary or contain an out-of-range length) MUST terminate the connection with a "decode_error" alert. as description of the alert in Section 6.2: decode_error A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This alert is used for errors where the message does not conform to the formal protocol syntax. In specific about Client Hello, in Section 4.1.2: If negotiating a version of TLS prior to 1.3, a server MUST check that the message either contains no data after legacy_compression_methods or that it contains a valid extensions block with no data following. If not, then it MUST abort the handshake with a "decode_error" alert. And specific handling of Certificate from server in Section 4.4.2.4: If the server supplies an empty Certificate message, the client MUST abort the handshake with a "decode_error" alert. Description of "illegal_parameter" in Section 6: Peers which receive a message which is syntactically correct but semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) MUST terminate the connection with an "illegal_parameter" alert. Alert description in Section 6.2: illegal_parameter A field in the handshake was incorrect or inconsistent with other fields. This alert is used for errors which conform to the formal protocol syntax but are otherwise incorrect. (it's also mentioned in over a dozen places in the draft) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
- Re: [TLS] Malformed Finished handling Hubert Kario
- Re: [TLS] Malformed Finished handling Hubert Kario
- Re: [TLS] Malformed Finished handling Hubert Kario
- [TLS] Malformed Finished handling Hubert Kario
- Re: [TLS] Malformed Finished handling Salz, Rich
- Re: [TLS] Malformed Finished handling Hubert Kario
- Re: [TLS] Malformed Finished handling Eric Rescorla
- Re: [TLS] Malformed Finished handling Eric Rescorla
- Re: [TLS] Malformed Finished handling Martin Thomson