On Mon, Oct 09, 2017 at 07:21:01PM +0200, Martin Rex wrote: > Ilari Liusvaara <ilariliusva...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
