Ilari Liusvaara <ilariliusva...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
