6 ms·

First off, the HTTP HTTP 301s to the HTTPS site, so HTTPS is still the likely trigger. Second, I see that whatever client he's using is specifying a very old T

by gjf 2y ago

First off, the HTTP HTTP 301s to the HTTPS site, so HTTPS is still the likely trigger. Second, I see that whatever client he's using is specifying a very old TLS 1.0. If its not MTU (which others have mentioned), then my guess would be a firewall with a policy specifying a minimum TLS version, and dropping this connection on the floor.

deleted 2y ago
[deleted]
johnp_ 2y ago
Certainly weird that wireshark shows TLSv1 while curl shows TLSv1.3. That shouldn't happen unless something interfered with the Client Hello. (or the wireshark version is outdated)
- gregw2 2y ago
  Ran into this myself about 10 days ago. If a TLS handshake is aborted partway through, Wireshark will label it “TLSv1”. It actually retroactively labels the 1.0 TLS packets as 1.3 after a successful TLS 1.3 handshake finishes. This makes sense because a TLSv1.3 handshake actually starts as 1.0 and then upgrades to 1.3 only with IIRC the Server Hello response to the ClientHello. The following links document this behavior, in case you or your organization’s security team is nervous TLSv1 is actually being used: https://superuser.com/a/1618420 https://superuser.com/a/1618420 https://ask.wireshark.org/question/24276/how-does-wireshark-identify-tls13/ https://ask.wireshark.org/question/24276/how-does-wireshark-... https://gitlab.com/wireshark/wireshark/-/issues/16114 https://gitlab.com/wireshark/wireshark/-/issues/16114
  - johnp_ 2y ago
    Oh, indeed, that's quite surprising. A TLSv1.3 Client Hello always contains the supported_versions extension, which should allow wireshark to label it correctly, regardless of whether or not the handshake actually finishes. Though, tbf, it does say TLSv1 and not TLSv1.0. I wonder how it would look had TLSv1.3 been named TLSv2.0 after all... edit: Ah, that GitLab link lead me to https://gitlab.com/wireshark/wireshark/-/issues/19515 https://gitlab.com/wireshark/wireshark/-/issues/19515 which is a recent discussion around this topic and https://gitlab.com/wireshark/wireshark/-/merge_requests/13771 https://gitlab.com/wireshark/wireshark/-/merge_requests/1377... already dealt with it :)

by gjf 2y ago

deleted 2y ago

[deleted]

johnp_ 2y ago

Certainly weird that wireshark shows TLSv1 while curl shows TLSv1.3. That shouldn't happen unless something interfered with the Client Hello. (or the wireshark version is outdated)

gregw2 2y ago
Ran into this myself about 10 days ago. If a TLS handshake is aborted partway through, Wireshark will label it “TLSv1”. It actually retroactively labels the 1.0 TLS packets as 1.3 after a successful TLS 1.3 handshake finishes. This makes sense because a TLSv1.3 handshake actually starts as 1.0 and then upgrades to 1.3 only with IIRC the Server Hello response to the ClientHello. The following links document this behavior, in case you or your organization’s security team is nervous TLSv1 is actually being used: https://superuser.com/a/1618420 https://superuser.com/a/1618420 https://ask.wireshark.org/question/24276/how-does-wireshark-identify-tls13/ https://ask.wireshark.org/question/24276/how-does-wireshark-... https://gitlab.com/wireshark/wireshark/-/issues/16114 https://gitlab.com/wireshark/wireshark/-/issues/16114
- johnp_ 2y ago
  Oh, indeed, that's quite surprising. A TLSv1.3 Client Hello always contains the supported_versions extension, which should allow wireshark to label it correctly, regardless of whether or not the handshake actually finishes. Though, tbf, it does say TLSv1 and not TLSv1.0. I wonder how it would look had TLSv1.3 been named TLSv2.0 after all... edit: Ah, that GitLab link lead me to https://gitlab.com/wireshark/wireshark/-/issues/19515 https://gitlab.com/wireshark/wireshark/-/issues/19515 which is a recent discussion around this topic and https://gitlab.com/wireshark/wireshark/-/merge_requests/13771 https://gitlab.com/wireshark/wireshark/-/merge_requests/1377... already dealt with it :)