Why does Wireshark show Version TLS 1.2 here instead of TLS 1.3?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












6















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:



HTML Response



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 ClientHelloWireshark HelloRetryWireshark ClientHello 2Wireshark ServerHello










share|improve this question






















  • 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
















6















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:



HTML Response



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 ClientHelloWireshark HelloRetryWireshark ClientHello 2Wireshark ServerHello










share|improve this question






















  • 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














6












6








6








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:



HTML Response



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 ClientHelloWireshark HelloRetryWireshark ClientHello 2Wireshark ServerHello










share|improve this question














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:



HTML Response



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 ClientHelloWireshark HelloRetryWireshark ClientHello 2Wireshark ServerHello







wireshark






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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


















  • 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











2 Answers
2






active

oldest

votes


















12














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:



Wireshark supported versions






share|improve this answer


















  • 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


















3















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






share|improve this answer






















    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
    );



    );













    draft saved

    draft discarded


















    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









    12














    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:



    Wireshark supported versions






    share|improve this answer


















    • 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















    12














    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:



    Wireshark supported versions






    share|improve this answer


















    • 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













    12












    12








    12







    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:



    Wireshark supported versions






    share|improve this answer













    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:



    Wireshark supported versions







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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












    • 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











    3















    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






    share|improve this answer



























      3















      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






      share|improve this answer

























        3












        3








        3








        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






        share|improve this answer














        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







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 31 '18 at 12:06









        LekensteynLekensteyn

        1312




        1312



























            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?