Re: [TLS] Suspicious behaviour of TLS server implementations

"Andreas Walz" <andreas.walz@hs-offenburg.de> Wed, 21 September 2016 07:21 UTC

Return-Path: <andreas.walz@hs-offenburg.de>
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 36E1812B18B for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 00:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.315
X-Spam-Level:
X-Spam-Status: No, score=-4.315 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de
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 tAEJAwxZZ3Bh for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 00:21:16 -0700 (PDT)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714C512B17F for <tls@ietf.org>; Wed, 21 Sep 2016 00:21:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id AA42EE7C2BA for <tls@ietf.org>; Wed, 21 Sep 2016 09:21:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1474442472; x= 1475306473; bh=0TvF1Z0uGcU9W0LO7+iyEtpnPcci8bTRvflobJ+vIGU=; b=m q+Oc2QklKU0f+/zJSPX7PLUc5n/Ej8IvSpkb4FYRWqXu6XzHg4IS+VLtmvzEhAas geuZh8q5oV7nPKonbYZZlI6TgqLpZR5ZVcA9PvgJDH731g9pQrlMsHQntqV6AcTj Z7fyYOIungGlsSfYSjAgme5K0MLFwoGMy0Q1ih6cNI=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKUBN7-7NeHp for <tls@ietf.org>; Wed, 21 Sep 2016 09:21:12 +0200 (CEST)
Received: from gwia2.rz.hs-offenburg.de (stud.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id F2D11E7C2B5 for <tls@ietf.org>; Wed, 21 Sep 2016 09:21:11 +0200 (CEST)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Wed, 21 Sep 2016 09:21:11 +0200
Message-Id: <57E25106020000AC0011BF3A@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1
Date: Wed, 21 Sep 2016 09:21:10 +0200
From: "Andreas Walz" <andreas.walz@hs-offenburg.de>
To: <tls@ietf.org>
References: <57D2E218020000AC0011B17E@gwia2.rz.hs-offenburg.de>, <20160909152901.9008C1A552@ld9781.wdf.sap.corp> <1473853106532.3256@cs.auckland.ac.nz> <57D96E34020000AC0011B73F@gwia2.rz.hs-offenburg.de>
In-Reply-To: <57D96E34020000AC0011B73F@gwia2.rz.hs-offenburg.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1F29A7F6.0__="
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yhg2SSKl1Mfx22Va9u1G76bI37E>
Subject: Re: [TLS] Suspicious behaviour of TLS server implementations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Sep 2016 07:21:20 -0000

Dear all,

sorry for bringing up this thread again. We were doing some further studies with TLS implementations (all TLS 1.2) for embedded systems and found more cases where, within substructures of handshake messages, trailing data without any associated field in the specification is *not* rejected. One example is the "Supported Elliptic Curves Extension" [RFC4492]:

struct {
    NamedCurve elliptic_curve_list<1..2^16-1>;
} EllipticCurveList;

which is parsed as if there was an additional field "trailing" absorbing all remaining data:

struct {
    NamedCurve elliptic_curve_list<1..2^16-1>;
    opaque trailing[];
} EllipticCurveList;

(There are various other places where this happens.)

I must say I'm having hard times finding any rationale behind ignoring such data rather than rejecting it (and aborting the handshake). In fact, most implementations do reject such messages and send a "decode_error" alert.

Do you see any argument why ignoring such trailing data would be acceptable (or even desirable)?

Thanks again and Cheers,
Andi Walz


___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany



>>> "Andreas Walz" <andreas.walz@hs-offenburg.de>; 09/14/16 4:20 PM >>>
Hi,

>>> Hubert Kario <hkario@redhat.com>; 09/12/16 6:56 PM >>>
> are you aware of the tlsfuzzer framework?
> https://github.com/tomato42/tlsfuzzer

@Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the repository before and I skimmed through the code. However, I didn't run the code and I don't know details about the way it is generating input. Is there some paper or presentation about it? 

>>> Peter Gutmann <pgut001@cs.auckland.ac.nz>; 09/14/16 1:39 PM >>>
> My code checks for extensions all the way down, but I could quite easily be
> persuaded that ignoring trailing garbage is OK too, based on what earlier
> versions of TLS did.  Like RFC 3546 originally did for extensions, some future
> RFC might add a new field at the end, so not failing on finding more data may
> be a good thing.  Or at least I can't see why it would be a bad thing.

@Peter Gutmann: Thanks for your take on that. Actually, and I might easily be missing something here, I do see some issues with adding new fields to the ClientHello in the future (i.e. following the "client_hello_extension_list"). As far as I can see, there is no way within a ClientHello to convey some kind of a version of the ClientHello format itself (as the ClientHello's version field is just indicating the highest version the client supports). That is, the only mechanism I see here is the same as the one that allowed to add extensions to a ClientHello message with RFC3546. However, that door has explicitly been closed therein in section 2.1 (as Hubert Kario pointed out)

    A server that supports the extensions mechanism MUST accept only
    client hello messages in either the original or extended ClientHello
    format, and (as for all other messages) MUST check that the amount of
    data in the message precisely matches one of these formats; if not
    then it MUST send a fatal "decode_error" alert.  This overrides the
    "Forward compatibility note" in [TLS].

A similar statement is given in RFC5246, section 7.4.1.2.:

    A server MUST accept ClientHello
    messages both with and without the extensions field, and (as for all
    other messages) it MUST check that the amount of data in the message
    precisely matches one of these formats; if not, then it MUST send a
    fatal "decode_error" alert.

Thus, to my understanding, any new field in the ClientHello would automatically break backward compatibility (at least with older compliant servers or unless everyone explicitly skips a MUST check in the interest of forward compatibility).

___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany





>>> Peter Gutmann <pgut001@cs.auckland.ac.nz>; 09/14/16 1:39 PM >>>
Martin Rex <mrex@sap.com>; writes:

>The actual problem is the design flaw in TLS that availability of null
>compression is not implied, but rather given a seperate codepoint, and the
>server choosing null compression and continuing even when it is not
>explicitly asserted by the client, is a server silently making up for that
>design flaw in the TLS spec.

Yup, and I'd say it's perfectly valid behaviour.  Compression is an optional
extra, but you need to explicitly specify that you don't want it, something
that's popular in the PKI world where you have a supposedly optional
capability that isn't actually optional so you need to fill it with a dummy
value to indicate that you don't care about it.

>Up to TLSv1.2, TLS extensions were purely optional, so an implementation that
>unconditionally ignores everything following compression methods is at least
>fully conforming to SSLv3, TLSv1.0 and TLSv1.1.
>
>For an TLS implementation that parses TLS extensions, the behaviour of what
>to do about trailing garbage is a different matter.  Personally I prefer
>aborting in case of garbage trailing TLS extensions.

My code checks for extensions all the way down, but I could quite easily be
persuaded that ignoring trailing garbage is OK too, based on what earlier
versions of TLS did.  Like RFC 3546 originally did for extensions, some future
RFC might add a new field at the end, so not failing on finding more data may
be a good thing.  Or at least I can't see why it would be a bad thing.

>What the server does in presence of multiple TLS extensions of the same type
>is implementation defined.  I think it would be extremely reasonable for a
>server to perform a simple plausibility check on decode whether it is
>decoding the same TLS extension more than once, and then abort with a
>decode_error alert, in order to have ambiguities caught early. Recognizing
>duplicate TLS extensions that the server does not support/implement does not
>(yet) create ambiguities (for that server) and requires more complex code, so
>I would not implement that check.

+1.  Remembering that you've already done a known extension is one thing, but
having to track a potentially arbitrary number of extensions that you don't
know what to do with anyway doesn't seem worthwhile.  And then there's the
same problem as with ignoring extra data at the end of the hello, at some
point a future RFC may define an extension where having duplicate copies makes
sense or is even required for things to work.  So you don't really gain
anything by ignoring duplicate unknown extensions, and will potentially break
things in the future if you do reject them.

Having said that, some extensions are purely signalling extensions, like EMS
and EtM.  I'm not sure if there's any problem with accepting doubles of those,
it could just be the other side being emphatic.  Consider how you'd need to
report this to the user, "shut down the TLS connection because I saw two
copies of some extension you've never heard of before", you can imagine what a
user who sees that would think of the anal-retentive &^@#* who added special
code to the handshake in order to reject it if this condition is encountered.

Peter.