Why does Wireshark show Version TLS 1.2 here instead of TLS 1.3?
Clash Royale CLAN TAG#URR8PPP
I'm accessing TLS 1.3 test server "https://tls13.pinterjann.is" via a java http client using TLS 1.3. Everything seems to work fine as the html response indicates:
What I don't understand: Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Is Wireshark just displaying the wrong Version or am I actually using TLS 1.2?
Thanks in advance for your support.
wireshark
|
show 1 more comment
I'm accessing TLS 1.3 test server "https://tls13.pinterjann.is" via a java http client using TLS 1.3. Everything seems to work fine as the html response indicates:
What I don't understand: Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Is Wireshark just displaying the wrong Version or am I actually using TLS 1.2?
Thanks in advance for your support.
wireshark
Is your copy of Wireshark up to date?
– Jesse P.
Dec 31 '18 at 3:57
1
Yes, I'm using Wireshark version 2.6.5.
– user120513
Dec 31 '18 at 4:06
1
Interestingly enough, it said 1.3 on one line but then said 1.0 on another, then 1.2 on yet another. Have you tried a different capture utility, such as Fiddler?
– Jesse P.
Dec 31 '18 at 4:15
No I didn't try another capture tool. Does Fiddler support displaying TLS 1.3 messages?
– user120513
Dec 31 '18 at 4:33
BTW: I found this capture cloudshark.org/captures/64d433b1585a on the internet, where the same thing happens. I guess it's an inaccurracy in the way Wireshark displays the version in the detail section.
– user120513
Dec 31 '18 at 4:36
|
show 1 more comment
I'm accessing TLS 1.3 test server "https://tls13.pinterjann.is" via a java http client using TLS 1.3. Everything seems to work fine as the html response indicates:
What I don't understand: Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Is Wireshark just displaying the wrong Version or am I actually using TLS 1.2?
Thanks in advance for your support.
wireshark
I'm accessing TLS 1.3 test server "https://tls13.pinterjann.is" via a java http client using TLS 1.3. Everything seems to work fine as the html response indicates:
What I don't understand: Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Is Wireshark just displaying the wrong Version or am I actually using TLS 1.2?
Thanks in advance for your support.
wireshark
wireshark
asked Dec 31 '18 at 1:17
user120513user120513
1516
1516
Is your copy of Wireshark up to date?
– Jesse P.
Dec 31 '18 at 3:57
1
Yes, I'm using Wireshark version 2.6.5.
– user120513
Dec 31 '18 at 4:06
1
Interestingly enough, it said 1.3 on one line but then said 1.0 on another, then 1.2 on yet another. Have you tried a different capture utility, such as Fiddler?
– Jesse P.
Dec 31 '18 at 4:15
No I didn't try another capture tool. Does Fiddler support displaying TLS 1.3 messages?
– user120513
Dec 31 '18 at 4:33
BTW: I found this capture cloudshark.org/captures/64d433b1585a on the internet, where the same thing happens. I guess it's an inaccurracy in the way Wireshark displays the version in the detail section.
– user120513
Dec 31 '18 at 4:36
|
show 1 more comment
Is your copy of Wireshark up to date?
– Jesse P.
Dec 31 '18 at 3:57
1
Yes, I'm using Wireshark version 2.6.5.
– user120513
Dec 31 '18 at 4:06
1
Interestingly enough, it said 1.3 on one line but then said 1.0 on another, then 1.2 on yet another. Have you tried a different capture utility, such as Fiddler?
– Jesse P.
Dec 31 '18 at 4:15
No I didn't try another capture tool. Does Fiddler support displaying TLS 1.3 messages?
– user120513
Dec 31 '18 at 4:33
BTW: I found this capture cloudshark.org/captures/64d433b1585a on the internet, where the same thing happens. I guess it's an inaccurracy in the way Wireshark displays the version in the detail section.
– user120513
Dec 31 '18 at 4:36
Is your copy of Wireshark up to date?
– Jesse P.
Dec 31 '18 at 3:57
Is your copy of Wireshark up to date?
– Jesse P.
Dec 31 '18 at 3:57
1
1
Yes, I'm using Wireshark version 2.6.5.
– user120513
Dec 31 '18 at 4:06
Yes, I'm using Wireshark version 2.6.5.
– user120513
Dec 31 '18 at 4:06
1
1
Interestingly enough, it said 1.3 on one line but then said 1.0 on another, then 1.2 on yet another. Have you tried a different capture utility, such as Fiddler?
– Jesse P.
Dec 31 '18 at 4:15
Interestingly enough, it said 1.3 on one line but then said 1.0 on another, then 1.2 on yet another. Have you tried a different capture utility, such as Fiddler?
– Jesse P.
Dec 31 '18 at 4:15
No I didn't try another capture tool. Does Fiddler support displaying TLS 1.3 messages?
– user120513
Dec 31 '18 at 4:33
No I didn't try another capture tool. Does Fiddler support displaying TLS 1.3 messages?
– user120513
Dec 31 '18 at 4:33
BTW: I found this capture cloudshark.org/captures/64d433b1585a on the internet, where the same thing happens. I guess it's an inaccurracy in the way Wireshark displays the version in the detail section.
– user120513
Dec 31 '18 at 4:36
BTW: I found this capture cloudshark.org/captures/64d433b1585a on the internet, where the same thing happens. I guess it's an inaccurracy in the way Wireshark displays the version in the detail section.
– user120513
Dec 31 '18 at 4:36
|
show 1 more comment
2 Answers
2
active
oldest
votes
Sorry, for the confusion, I was missing the exact TLS 1.3 semantics: For instance, in the Client Hello, the field "version" must contain the fixed value 0x0303 (TLS 1.2), while the prefered version is contained in the extension "supported versions".
From RFC 8446 (TLS 1.3 spec):
struct
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
ClientHello;
legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.
(See Appendix D for details about backward compatibility.)
This agrees with what Wireshark displays:
1
Nice find. Congrats.
– Jesse P.
Dec 31 '18 at 6:09
1
This was covered 4 days ago in a lecture at 35C3: media.ccc.de/v/… The "version intolerance" problem seems to be quite widespread on "enterprise" devices
– cg909
Dec 31 '18 at 13:19
add a comment |
Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Wireshark reports TLS 1.3 in the protocol column due to Server Hello containing a Supported Versions extension with TLS 1.3.
Recall that TLS sessions begin with a handshake to negotiate parameters such as the protocol version and ciphers. The client sends a Client Hello handshake message in a TLS record containing:
- TLS Record - Version: minimum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not really used and MUST be 0x0303 ("TLS 1.2") or 0x301 ("TLS 1.0") for compatibility purposes. Reference: RFC 8446 (page 79)
- Client Hello - Version: maximum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not used but MUST be set to 0x0303 ("TLS 1.2"). Reference: RFC 8446 (4.1.2. Client Hello)
- Client Hello - Supported Versions Extension: list of supported versions. This is the only value used by TLS 1.3 implementations (which may agree TLS 1.3, 1.2 or other versions). Reference: RFC 8446 (4.2.1. Supported Versions)
The server sends a Server Hello handshake message with:
- Server Hello - Version: negotiated version (for TLS 1.2 and before). If TLS 1.3 is negotiated, it MUST be set to 0x0303 ("TLS 1.2").
- Server Hello - Supported Versions: a single negotiated version (for TLS 1.3). Cannot be used to negotiate earlier versions.
So in TLS 1.2, the client sends a range of supported versions while a TLS 1.3 client sends a list of supported versions. The server will then pick a single version, but for compatibility purposes it will use a new field for selecting TLS 1.3 or newer.
(Even if a client advertises support for some version (e.g. via a TLS record version containing "TLS 1.0"), it could still fail the handshake though if the server agrees to this low version.)
Another thing to be aware of: Wireshark tries to interpret a packet immediately as it is received. At the time the Client Hello is received, it will not know the final version and therefore assume the TLS Record Version. When the Server Hello is received, it can adjust the version accordingly:
$ tshark -r test/captures/tls13-rfc8446.pcap
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
In a two-pass dissection (which also includes the Wireshark GUI), the agreed version will be known when it prints the results of the second pass:
$ tshark -r test/captures/tls13-rfc8446.pcap -2
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1.3 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
Test capture used above: https://github.com/wireshark/wireshark/blob/master/test/captures/tls13-rfc8446.pcap
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "496"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f55752%2fwhy-does-wireshark-show-version-tls-1-2-here-instead-of-tls-1-3%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sorry, for the confusion, I was missing the exact TLS 1.3 semantics: For instance, in the Client Hello, the field "version" must contain the fixed value 0x0303 (TLS 1.2), while the prefered version is contained in the extension "supported versions".
From RFC 8446 (TLS 1.3 spec):
struct
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
ClientHello;
legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.
(See Appendix D for details about backward compatibility.)
This agrees with what Wireshark displays:
1
Nice find. Congrats.
– Jesse P.
Dec 31 '18 at 6:09
1
This was covered 4 days ago in a lecture at 35C3: media.ccc.de/v/… The "version intolerance" problem seems to be quite widespread on "enterprise" devices
– cg909
Dec 31 '18 at 13:19
add a comment |
Sorry, for the confusion, I was missing the exact TLS 1.3 semantics: For instance, in the Client Hello, the field "version" must contain the fixed value 0x0303 (TLS 1.2), while the prefered version is contained in the extension "supported versions".
From RFC 8446 (TLS 1.3 spec):
struct
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
ClientHello;
legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.
(See Appendix D for details about backward compatibility.)
This agrees with what Wireshark displays:
1
Nice find. Congrats.
– Jesse P.
Dec 31 '18 at 6:09
1
This was covered 4 days ago in a lecture at 35C3: media.ccc.de/v/… The "version intolerance" problem seems to be quite widespread on "enterprise" devices
– cg909
Dec 31 '18 at 13:19
add a comment |
Sorry, for the confusion, I was missing the exact TLS 1.3 semantics: For instance, in the Client Hello, the field "version" must contain the fixed value 0x0303 (TLS 1.2), while the prefered version is contained in the extension "supported versions".
From RFC 8446 (TLS 1.3 spec):
struct
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
ClientHello;
legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.
(See Appendix D for details about backward compatibility.)
This agrees with what Wireshark displays:
Sorry, for the confusion, I was missing the exact TLS 1.3 semantics: For instance, in the Client Hello, the field "version" must contain the fixed value 0x0303 (TLS 1.2), while the prefered version is contained in the extension "supported versions".
From RFC 8446 (TLS 1.3 spec):
struct
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
ClientHello;
legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.
(See Appendix D for details about backward compatibility.)
This agrees with what Wireshark displays:
answered Dec 31 '18 at 5:16
user120513user120513
1516
1516
1
Nice find. Congrats.
– Jesse P.
Dec 31 '18 at 6:09
1
This was covered 4 days ago in a lecture at 35C3: media.ccc.de/v/… The "version intolerance" problem seems to be quite widespread on "enterprise" devices
– cg909
Dec 31 '18 at 13:19
add a comment |
1
Nice find. Congrats.
– Jesse P.
Dec 31 '18 at 6:09
1
This was covered 4 days ago in a lecture at 35C3: media.ccc.de/v/… The "version intolerance" problem seems to be quite widespread on "enterprise" devices
– cg909
Dec 31 '18 at 13:19
1
1
Nice find. Congrats.
– Jesse P.
Dec 31 '18 at 6:09
Nice find. Congrats.
– Jesse P.
Dec 31 '18 at 6:09
1
1
This was covered 4 days ago in a lecture at 35C3: media.ccc.de/v/… The "version intolerance" problem seems to be quite widespread on "enterprise" devices
– cg909
Dec 31 '18 at 13:19
This was covered 4 days ago in a lecture at 35C3: media.ccc.de/v/… The "version intolerance" problem seems to be quite widespread on "enterprise" devices
– cg909
Dec 31 '18 at 13:19
add a comment |
Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Wireshark reports TLS 1.3 in the protocol column due to Server Hello containing a Supported Versions extension with TLS 1.3.
Recall that TLS sessions begin with a handshake to negotiate parameters such as the protocol version and ciphers. The client sends a Client Hello handshake message in a TLS record containing:
- TLS Record - Version: minimum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not really used and MUST be 0x0303 ("TLS 1.2") or 0x301 ("TLS 1.0") for compatibility purposes. Reference: RFC 8446 (page 79)
- Client Hello - Version: maximum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not used but MUST be set to 0x0303 ("TLS 1.2"). Reference: RFC 8446 (4.1.2. Client Hello)
- Client Hello - Supported Versions Extension: list of supported versions. This is the only value used by TLS 1.3 implementations (which may agree TLS 1.3, 1.2 or other versions). Reference: RFC 8446 (4.2.1. Supported Versions)
The server sends a Server Hello handshake message with:
- Server Hello - Version: negotiated version (for TLS 1.2 and before). If TLS 1.3 is negotiated, it MUST be set to 0x0303 ("TLS 1.2").
- Server Hello - Supported Versions: a single negotiated version (for TLS 1.3). Cannot be used to negotiate earlier versions.
So in TLS 1.2, the client sends a range of supported versions while a TLS 1.3 client sends a list of supported versions. The server will then pick a single version, but for compatibility purposes it will use a new field for selecting TLS 1.3 or newer.
(Even if a client advertises support for some version (e.g. via a TLS record version containing "TLS 1.0"), it could still fail the handshake though if the server agrees to this low version.)
Another thing to be aware of: Wireshark tries to interpret a packet immediately as it is received. At the time the Client Hello is received, it will not know the final version and therefore assume the TLS Record Version. When the Server Hello is received, it can adjust the version accordingly:
$ tshark -r test/captures/tls13-rfc8446.pcap
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
In a two-pass dissection (which also includes the Wireshark GUI), the agreed version will be known when it prints the results of the second pass:
$ tshark -r test/captures/tls13-rfc8446.pcap -2
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1.3 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
Test capture used above: https://github.com/wireshark/wireshark/blob/master/test/captures/tls13-rfc8446.pcap
add a comment |
Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Wireshark reports TLS 1.3 in the protocol column due to Server Hello containing a Supported Versions extension with TLS 1.3.
Recall that TLS sessions begin with a handshake to negotiate parameters such as the protocol version and ciphers. The client sends a Client Hello handshake message in a TLS record containing:
- TLS Record - Version: minimum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not really used and MUST be 0x0303 ("TLS 1.2") or 0x301 ("TLS 1.0") for compatibility purposes. Reference: RFC 8446 (page 79)
- Client Hello - Version: maximum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not used but MUST be set to 0x0303 ("TLS 1.2"). Reference: RFC 8446 (4.1.2. Client Hello)
- Client Hello - Supported Versions Extension: list of supported versions. This is the only value used by TLS 1.3 implementations (which may agree TLS 1.3, 1.2 or other versions). Reference: RFC 8446 (4.2.1. Supported Versions)
The server sends a Server Hello handshake message with:
- Server Hello - Version: negotiated version (for TLS 1.2 and before). If TLS 1.3 is negotiated, it MUST be set to 0x0303 ("TLS 1.2").
- Server Hello - Supported Versions: a single negotiated version (for TLS 1.3). Cannot be used to negotiate earlier versions.
So in TLS 1.2, the client sends a range of supported versions while a TLS 1.3 client sends a list of supported versions. The server will then pick a single version, but for compatibility purposes it will use a new field for selecting TLS 1.3 or newer.
(Even if a client advertises support for some version (e.g. via a TLS record version containing "TLS 1.0"), it could still fail the handshake though if the server agrees to this low version.)
Another thing to be aware of: Wireshark tries to interpret a packet immediately as it is received. At the time the Client Hello is received, it will not know the final version and therefore assume the TLS Record Version. When the Server Hello is received, it can adjust the version accordingly:
$ tshark -r test/captures/tls13-rfc8446.pcap
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
In a two-pass dissection (which also includes the Wireshark GUI), the agreed version will be known when it prints the results of the second pass:
$ tshark -r test/captures/tls13-rfc8446.pcap -2
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1.3 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
Test capture used above: https://github.com/wireshark/wireshark/blob/master/test/captures/tls13-rfc8446.pcap
add a comment |
Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Wireshark reports TLS 1.3 in the protocol column due to Server Hello containing a Supported Versions extension with TLS 1.3.
Recall that TLS sessions begin with a handshake to negotiate parameters such as the protocol version and ciphers. The client sends a Client Hello handshake message in a TLS record containing:
- TLS Record - Version: minimum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not really used and MUST be 0x0303 ("TLS 1.2") or 0x301 ("TLS 1.0") for compatibility purposes. Reference: RFC 8446 (page 79)
- Client Hello - Version: maximum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not used but MUST be set to 0x0303 ("TLS 1.2"). Reference: RFC 8446 (4.1.2. Client Hello)
- Client Hello - Supported Versions Extension: list of supported versions. This is the only value used by TLS 1.3 implementations (which may agree TLS 1.3, 1.2 or other versions). Reference: RFC 8446 (4.2.1. Supported Versions)
The server sends a Server Hello handshake message with:
- Server Hello - Version: negotiated version (for TLS 1.2 and before). If TLS 1.3 is negotiated, it MUST be set to 0x0303 ("TLS 1.2").
- Server Hello - Supported Versions: a single negotiated version (for TLS 1.3). Cannot be used to negotiate earlier versions.
So in TLS 1.2, the client sends a range of supported versions while a TLS 1.3 client sends a list of supported versions. The server will then pick a single version, but for compatibility purposes it will use a new field for selecting TLS 1.3 or newer.
(Even if a client advertises support for some version (e.g. via a TLS record version containing "TLS 1.0"), it could still fail the handshake though if the server agrees to this low version.)
Another thing to be aware of: Wireshark tries to interpret a packet immediately as it is received. At the time the Client Hello is received, it will not know the final version and therefore assume the TLS Record Version. When the Server Hello is received, it can adjust the version accordingly:
$ tshark -r test/captures/tls13-rfc8446.pcap
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
In a two-pass dissection (which also includes the Wireshark GUI), the agreed version will be known when it prints the results of the second pass:
$ tshark -r test/captures/tls13-rfc8446.pcap -2
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1.3 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
Test capture used above: https://github.com/wireshark/wireshark/blob/master/test/captures/tls13-rfc8446.pcap
Why does Wireshark show in the overview Protocol TLSv1.3 but in the details Version TLS 1.2?
Wireshark reports TLS 1.3 in the protocol column due to Server Hello containing a Supported Versions extension with TLS 1.3.
Recall that TLS sessions begin with a handshake to negotiate parameters such as the protocol version and ciphers. The client sends a Client Hello handshake message in a TLS record containing:
- TLS Record - Version: minimum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not really used and MUST be 0x0303 ("TLS 1.2") or 0x301 ("TLS 1.0") for compatibility purposes. Reference: RFC 8446 (page 79)
- Client Hello - Version: maximum supported TLS version (in TLS 1.2 and before). In TLS 1.3, this field is not used but MUST be set to 0x0303 ("TLS 1.2"). Reference: RFC 8446 (4.1.2. Client Hello)
- Client Hello - Supported Versions Extension: list of supported versions. This is the only value used by TLS 1.3 implementations (which may agree TLS 1.3, 1.2 or other versions). Reference: RFC 8446 (4.2.1. Supported Versions)
The server sends a Server Hello handshake message with:
- Server Hello - Version: negotiated version (for TLS 1.2 and before). If TLS 1.3 is negotiated, it MUST be set to 0x0303 ("TLS 1.2").
- Server Hello - Supported Versions: a single negotiated version (for TLS 1.3). Cannot be used to negotiate earlier versions.
So in TLS 1.2, the client sends a range of supported versions while a TLS 1.3 client sends a list of supported versions. The server will then pick a single version, but for compatibility purposes it will use a new field for selecting TLS 1.3 or newer.
(Even if a client advertises support for some version (e.g. via a TLS record version containing "TLS 1.0"), it could still fail the handshake though if the server agrees to this low version.)
Another thing to be aware of: Wireshark tries to interpret a packet immediately as it is received. At the time the Client Hello is received, it will not know the final version and therefore assume the TLS Record Version. When the Server Hello is received, it can adjust the version accordingly:
$ tshark -r test/captures/tls13-rfc8446.pcap
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
In a two-pass dissection (which also includes the Wireshark GUI), the agreed version will be known when it prints the results of the second pass:
$ tshark -r test/captures/tls13-rfc8446.pcap -2
1 0.000000 10.9.0.1 → 10.9.0.2 TLSv1.3 304 Client Hello
2 0.002634 10.9.0.2 → 10.9.0.1 TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
3 0.005266 10.9.0.1 → 10.9.0.2 TLSv1.3 130 Change Cipher Spec, Application Data
4 0.005772 10.9.0.2 → 10.9.0.1 TLSv1.3 468 Application Data
...
Test capture used above: https://github.com/wireshark/wireshark/blob/master/test/captures/tls13-rfc8446.pcap
answered Dec 31 '18 at 12:06
LekensteynLekensteyn
1312
1312
add a comment |
add a comment |
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f55752%2fwhy-does-wireshark-show-version-tls-1-2-here-instead-of-tls-1-3%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Is your copy of Wireshark up to date?
– Jesse P.
Dec 31 '18 at 3:57
1
Yes, I'm using Wireshark version 2.6.5.
– user120513
Dec 31 '18 at 4:06
1
Interestingly enough, it said 1.3 on one line but then said 1.0 on another, then 1.2 on yet another. Have you tried a different capture utility, such as Fiddler?
– Jesse P.
Dec 31 '18 at 4:15
No I didn't try another capture tool. Does Fiddler support displaying TLS 1.3 messages?
– user120513
Dec 31 '18 at 4:33
BTW: I found this capture cloudshark.org/captures/64d433b1585a on the internet, where the same thing happens. I guess it's an inaccurracy in the way Wireshark displays the version in the detail section.
– user120513
Dec 31 '18 at 4:36