Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Ilari Liusvaara <[e-mail]>]

On Tue, Oct 10, 2017 at 10:52:26AM +0200, Martin Rex wrote:
> Ilari Liusvaara <[e-mail]> wrote:
> [ Charset UTF-8 unsupported, converting... ]

Lol.

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

Visible content-types cause problems with post-handshake
authentication.

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

Well, these annoying middleboxes do care about that.
 
> 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).

For that, even more annoying than the invisbile content-types is record
padding (actual security improvment). If the content-type was always in
fixed place, one could usually (at least for GCM and POLY1305 modes)
compute the masking value pretty fast, but that does not work because of
padding.


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

Unfortunately, what breaks is mostly not MITM boxes, since ones that
are not especially badly coded know not to try to forward unknown
extensions (which could, e.g., trigger TLS 1.3).

This is about "non-malicious" middleboxes. I put that in quotes,
because I have real problems trying to come up with any sort of "legit"
reason why these middleboxes try to parse ServerHello (reverse-proxy
middleboxes are different story, but the problematic middleboxes appear
to be forward proxies).

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

Aargh, The last point is wrong in this context (trying to disguise TLS
1.3 handshake as TLS 1.2 stateful session resumption). The dummy zeros
for compatiblity would form dummy session and compression fields. Of
course you do not want to insert those if you got session and
compression fields already.

The two dummy zeros are needed in less annoying compatiblity hack.


> > - 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. :)

Well, if there is no client certificate, the final client CCS followed by
encrypted handshake record would be end-of-handshake (since the next message
would be Client Finished, which always ends the handshake in TLS 1.3).
However, if there is client certificate, it would not be, since it would
then tag the first record of client certificate.

(On the server side, the CCS would be between ServerHello and
EncryptedExtensions, and EncryptedExtensions would get tagged as
handshake).

If dealing with this most annoying kind of middlebox, moving when this
fake CCS is inserted is not an option, since trying to move it makes
the middlebox choke.



-Ilari