Re: [TLS] Suspicious behaviour of TLS server implementations

Peter Gutmann <> Wed, 14 September 2016 11:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11A6612B302 for <>; Wed, 14 Sep 2016 04:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.708
X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SVtI61peTy-5 for <>; Wed, 14 Sep 2016 04:38:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07C1012B6A1 for <>; Wed, 14 Sep 2016 04:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1473853115; x=1505389115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y1r9nVAcRvT+iKHSymx/poyBmyJEJac/h1iuEEKSkOY=; b=1XX/aM7hb8UFIxqRMsoEAYfzmcIrgS/uQPAgOFJbYHuP00KaHNbdEcGW iq/L/8yW9GF6FK1fEYe+nf+scaA0fK9eYNYiRW9EZvRqHSHY2xVk3twsH jiDXQMHjejCy2K4skja7OClG6HqFO5bUgCWEwavRiKZIdbygIvY3U2aGf cYc2OkASVei65Xz9tHwj4W8rRP5LHs51R1la5gma1tcyVF1AkFljGgk+j TYX9S/HvNeE9JuAqOlvgi0urnPFyU6c56pjOWZG8B3XVUpwbStgoFuFhZ 5+hjIalgueyWKw/GbvVwt5Xq/65soYcjiWTDZ+u9iibpuALJR0/k1692K g==;
X-IronPort-AV: E=Sophos;i="5.30,333,1470657600"; d="scan'208";a="105854937"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 14 Sep 2016 23:38:32 +1200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 14 Sep 2016 23:38:32 +1200
Received: from ([fe80::8081:99e3:dee2:203]) by ([fe80::8081:99e3:dee2:203%14]) with mapi id 15.00.1178.000; Wed, 14 Sep 2016 23:38:32 +1200
From: Peter Gutmann <>
To: Andreas Walz <>, "" <>
Thread-Topic: [TLS] Suspicious behaviour of TLS server implementations
Thread-Index: AQHSCqXVmMdwMkXxhEmPq8Svce2cg6Bwf1GAgAhiD74=
Date: Wed, 14 Sep 2016 11:38:31 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Suspicious behaviour of TLS server implementations
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Sep 2016 11:38:49 -0000

Martin Rex <> 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.