Ask Your Question
0

TLS 1.3 Hello Retry Messages

asked 2019-07-11 18:28:09 +0000

rbecker gravatar image

updated 2019-07-11 19:09:58 +0000

Jaap gravatar image

Wireshark 3.0.2 seems to expect TLS 1.3 Hello Retry Messages as specified before draft-ietf-tls-tls13 version 22, and not the current version of the RFC 8446.

Specifically, as far as I can tell, before version 22, the Hello Retry Message was much simpler than after that version. It had just the protocol version, cipher suite, and extensions. Since version 22, the message is pretty much the same as the Server Hello including a (non-random) random field, compression method, etc.

By the way, there is something that might be related in comment #83 for Bug 12779, but I don't understand what this comment is about.

What am I missing?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-07-20 17:51:31 +0000

Lekensteyn gravatar image

updated 2019-07-20 17:52:11 +0000

Wireshark supports TLS 1.3 since Wireshark 2.6.0. It of course supports the final RFC 8446 version, but currently supports draft 18 up to draft 28 as well. Draft 18 has been deployed and stalled for a year due to "middleboxes" that broke connections: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/.

In draft 22, the format of Server Hello and Hello Retry Request messages have been modified to look like a TLS 1.2 Server Hello, precisely to avoid breaking connections as described above. The comment 83 of bug 12779 describes the characteristics of the attached capture file:

Using the current TLS 1.3 draft -22 spec (tentative, the changes are in tlswg/tls13-spec git master, but not as I-D). Main change is middlebox compatibility (version negotiation, HRR, ChangeCipherSpec).

At that time of writing, draft -22 of the TLS 1.3 Internet Draft (I-D) has not been released yet, hence "tentative". "tlswg/tls13-spec git master" refers to the Git source repository of the TLS Working Group, https://github.com/tlswg/tls13-spec. The "middlebox compatibility" changes are:

  • Version negotiation: the "supported_versions" TLS extension was previously used to advertise TLS 1.3 support in Client Hello messages while servers directly responsed with a Server Hello message that is different. Since draft 22, this extension is also used in Server Hello and Hello Retry Request messages to advertise TLS 1.3 support.
  • Hello Retry Request (HRR): this message was changed in draft 22 to look similar to a Server Hello message. TLS 1.2 parsers as used by middleboxes would thus still be able to recognize this message while TLS 1.3 implementations can understand its true semantics.
  • ChangeCipherSpec: In TLS 1.2 and before, the ChangeCipherSpec message indicates that everything from that point on would be encrypted. This fact is used in draft 23 to ensure that middleboxes stop their attempts to parse the data. In TLS 1.3, the server starts sending encrypted handshake messages (Encrypted Extensions, Certificate, etc.) following this. See also RFC 8446, Appendix D.4.
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-07-11 18:28:09 +0000

Seen: 3,196 times

Last updated: Jul 20 '19