Re: [TLS] Update on TLS 1.3 Middlebox Issues

mrex@sap.com (Martin Rex) Tue, 10 October 2017 08:52 UTC

Return-Path: <mrex@sap.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 58D3D134AE7 for <tls@ietfa.amsl.com>; Tue, 10 Oct 2017 01:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 h55fhwMu5pU6 for <tls@ietfa.amsl.com>; Tue, 10 Oct 2017 01:52:29 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC43134AEC for <tls@ietf.org>; Tue, 10 Oct 2017 01:52:28 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3yB9py4pK0z25WN; Tue, 10 Oct 2017 10:52:26 +0200 (CEST)
X-purgate-ID: 152705::1507625546-00007EC7-6FC01518/0/0
X-purgate-size: 4816
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3yB9py2m3szGpJK; Tue, 10 Oct 2017 10:52:26 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 54FF5404A; Tue, 10 Oct 2017 10:52:26 +0200 (CEST)
In-Reply-To: <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII>
References: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com> <20171007091720.012fdb7b@pc1> <CAMfhd9W-=-b4V0tX74k=thE9J2Vet-RH7a-XzkxLutRMT2_5Pg@mail.gmail.com> <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII> <20171009172101.BD9C8404A@ld9781.wdf.sap.corp> <20171009181631.un6hecfgsc7gt5hv@LK-Perkele-VII>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Tue, 10 Oct 2017 10:52:26 +0200 (CEST)
CC: Martin Rex <mrex@sap.com>, Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20171010085226.54FF5404A@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ckMWU_NRncpD_z8UD2sRm-fwHSA>
Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 10 Oct 2017 08:52:32 -0000

Ilari Liusvaara <ilariliusvaara@welho.com>; wrote:
[ Charset UTF-8 unsupported, converting... ]
> On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote:
>> 
>> Fixing the backwards-incompatibilities in the TLS record layer
>> would be terribly useful for streaming-optimized IO layers as well,
>> i.e. ensure the the TLS record properly identifies ContentType,
>> and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message.
> 
> Unfortunately, doing that would do really bad things to security.

Nope, none at all.  I'm _not_ asking for protocol changes, just that
the TLS handshake continues to end with CCS + HS, and ContentTypes
remain visible.  Contents of all handshake messages, and whether
and how that content is protected, remains subject to negotiated
protocol version which may vary significantly.


> 
> And the middleboxes I am talking about actually parse every cleartext
> handshake message. Change anything in any message and they fail. And
> fixing some known vulnerabilities in TLS 1.2 is not possible without
> changing the structures around.

Changing the contents of TLS handshake messages _other_ than
ClientHello+ServerHello is fine with me.  I also don't care which
of the handshake messages are clear vs. encrypted.

What I'm mainly asking for is keeping TLS record ContentType visible
(Handshake, AppData, CCS, Alert), and having a CCS before the final
Handshake record of a TLS handshake.  I'm really looking *ONLY* at
the TLS record layer semantics.

I have an issue with the borked TLS record layer protocol at the *ENDPOINT*,
because TLSv1.3 is never going to work as a drop-in replacement for us with
the current TLS record layer breakage.  This is about
(a) streaming-optimized IO for the handshake phase
(b) CCS to recognize the final step of the handshake phase
(c) and Content-Type visible Alerts to distinguish
End-of-Connection alerts (both fatal error or warning-level
close_notify) from next AppData record -- so that the body
of an AppData record can be left in the network receive buffers
and be visible through "network readable" socket event(s).

Having to redesign the entire application network read event model
in order to juggle around with an unprotected-but-not-yet-processible
AppData record would be a royal PITA, as much as not being able to
recognize premature client-side termination of a longrunning request
(which Web Browser navigation and complex page designs cause all the time).


> 
> In fact, I think the record layer changes in TLS 1.3 actually _reduce_
> intolerance, not _increase_ it. If your middlebox is not as anal as I
> described above, it probably falls into copying data back and forth
> when it loses the handshake. However, the changes into ServerHello
> could easily cause trouble even with such middleboxes.

I personally hate network middleboxes other than plain NAT, and I'm
violently opposed to MITMs (aka TLS-inspecting network middleboxes).
I will certainly not mind if those latter break.  Broken non-malicious
middleboxes are obnoxious, too, and create a significant & needless
support load.  A lot of our customers use some kind of totally broken
transparent internet proxies, which let TCP connect through, but
silently close the network connection after TLS ClientHello was sent.

Such behaviour is indistinguishable from a choking TLS implementation,
such as Microsoft IIS with SChannel (receiving SSLv3 ClientHello with
ClientHello.client_version=(3,3) or a Win2012+ IIS receiving ClientHello
without the optional TLS extension SNI).

And when telling customers to check their firewall rules, they often
come back saying: "but telnet connects".  Yup, braindead firewall.


> 
> Here what might work getting around those really annoying middleboxes
> (and this is pretty nasty):
> 
> - Add back the session field, echo field from client
>
> - Add dummy zero into place of compression method, so TLS 1.2 parsers
>   can parse the message.
>
> - Add two zeros into ServerHello so the message can be parsed the same
>   way as TLS 1.2.
 

You mean for ServerHello?  Yes, it would be highly preferable to
make ServerHello fully backwards compatible (with respect to the PDU parser)
so that you don't have to change horses midway while parsing ServerHello.


> - Fix ServerVersion at TLS 1.2, send true version in supported_versions
>   extension.

wfm.


> - If the version is TLS 1.3, the session id is non-empty and 0-RTT was
>   not accepted, insert fake ChangeCipherSpec message immediately after
>   ServerHello and change outer content-type of the next record to 22
>   (instead of 23). The client can do the same.

fake CCS before the final HS of a TLS handshake would make me happy. :)


-Martin