Re: [TLS] Update on TLS 1.3 Middlebox Issues

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 09 October 2017 18:16 UTC

Return-Path: <ilariliusvaara@welho.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 A4D8513475B for <tls@ietfa.amsl.com>; Mon, 9 Oct 2017 11:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 O7CZxPkfYrnB for <tls@ietfa.amsl.com>; Mon, 9 Oct 2017 11:16:38 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19417134670 for <tls@ietf.org>; Mon, 9 Oct 2017 11:16:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 6A9CEB514F; Mon, 9 Oct 2017 21:16:35 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id rlWaV-_uvFm7; Mon, 9 Oct 2017 21:16:35 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 8FD482313; Mon, 9 Oct 2017 21:16:31 +0300 (EEST)
Date: Mon, 9 Oct 2017 21:16:31 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Rex <mrex@sap.com>
Cc: Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20171009172101.BD9C8404A@ld9781.wdf.sap.corp>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xGliKiMcb5BRnHdPNpmceCTQYxA>
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: Mon, 09 Oct 2017 18:16:40 -0000

On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote:
> Ilari Liusvaara <ilariliusvaara@welho.com>; wrote:
> >
> > And even if the changes might not be directly consequential to
> > security, the changes to get through some more annoying middleboxes
> > might be quite annoying to implement.
> > 
> > E.g. there probably are several different middeboxes that have a
> > configuration that actually checks that the handshake looks valid,
> > which includes checks for things like ChangeCipherSpec being
> > present in both directions, even for resumption; while the non-
> > resumption mode might even verify the authentication signatures in
> > the handshake and not letting server send non-handshake messages
> > before sending its 2nd flight. Ugh, getting around those would be
> > pretty nasty.
> 
> 
> 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.

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.

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.


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.
- Fix ServerVersion at TLS 1.2, send true version in supported_versions
  extension.
- 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.

This might be able to make the middlebox think that first part of
the handshake is actually TLS 1.2 stateful session resumption. But as
said, blech at the hack. Hmm... Ciphersuites could cause problems
still.


With less annoying middleboxes, the following would also work:

- Add two zeros into ServerHello so the message can be parsed the same
  way as TLS 1.2.


And with slightly more annoying than that:

- Add two zeros into ServerHello so the message can be parsed the same
  way as TLS 1.2.
- Fix ServerVersion at TLS 1.2, send true version in supported_versions
  extension.




-Ilari