Re: [TLS] Malformed Finished handling
Hubert Kario <hkario@redhat.com> Mon, 09 July 2018 12:04 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 879D6126BED for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 05:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 BxQ5Kvj7awio for <tls@ietfa.amsl.com>; Mon, 9 Jul 2018 05:04:39 -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 395D5124C04 for <tls@ietf.org>; Mon, 9 Jul 2018 05:04:39 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D3CD9401EF05; Mon, 9 Jul 2018 11:29:30 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-200-16.brq.redhat.com [10.40.200.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id A5A4651E3; Mon, 9 Jul 2018 11:29:29 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Date: Mon, 09 Jul 2018 13:29:28 +0200
Message-ID: <2130941.FryZTEcNbp@pintsize.usersys.redhat.com>
In-Reply-To: <CABcZeBOAamJ-agBeKObjVEM9w-MUV1nYtDctBc1iexmGta+gDg@mail.gmail.com>
References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> <CABcZeBOAamJ-agBeKObjVEM9w-MUV1nYtDctBc1iexmGta+gDg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart382788306.0sBPEuVBLf"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 09 Jul 2018 11:29:30 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 09 Jul 2018 11:29:30 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.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/fTZnapfETzeGUsEGqaz-X01SOe0>
Subject: Re: [TLS] Malformed Finished handling
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 09 Jul 2018 12:04:41 -0000
On Wednesday, 4 July 2018 18:54:10 CEST Eric Rescorla wrote: > On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario <hkario@redhat.com> wrote: > > On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote: > > > I think it's a close call, because the length is sort of external to the > > > language. > > > > which language? the decode_error alert description literally says "length > > of > > the message was incorrect." > > The protocol definition language. Sorry, I really don't see it. There are multiple references to "length" in the draft, and as far as I can tell, all are quite consistent. > -Ekr > > > > That's why, for instance, NSS sends "illegal_parameter". So, > > > absent specific text about this value, I think this is something we can > > > leave to the implementations. > > > > but the text is explicit, if a message continues past message boundary, > > the > > correct response is decode_error. Decode_error is also consistent with the > > way > > above-expected length Client Hello MUST be handled. > > > > Just because the description of the message uses a single opaque array > > doesn't > > make this message syntactically any different from other Handshake > > protocol > > message. > > > > if the interpretation of "I know this _message_ _length_ is wrong because > > of > > some other values I negotiated before, so I'll send illegal_parameter" was > > correct, then overflow_error, decrypt_error and probably few others would > > also > > need to be replaced with illegal_parameter... > > > > > -Ekr > > > > > > On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario <hkario@redhat.com> wrote: > > > > 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 > > > > _______________________________________________ > > > > TLS mailing list > > > > TLS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > > 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 -- 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