Ask Your Question

Revision history [back]

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 https://tools.ietf.org/html/rfc8446#appendix-D.4

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 https://tools.ietf.org/html/rfc8446#appendix-D.4RFC 8446, Appendix D.4.