Re: [TLS] Update on TLS 1.3 Middlebox Issues

[[e-mail] (Martin Rex)]

Ilari Liusvaara <[e-mail]> 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