How to test which version of TLS my .NET client is using?

Question

I support a .NET site which (amongst many, MANY, other things) talks to remote APIs from supplier systems.

We want to upgrade to support TLS 1.2 We're hoping to do so as per this question: Are there .NET implementation of TLS 1.2?

But how do I check that this is actually working once I've made the change.

Ideally one of my supplier sites would start using TLS 1.2 ONLY and then my test could just be "can we talk to that supplier now?" But we don't have that. I'm guessing I can do something with a packet sniffer of some sort, but I wouldn't know what I was looking for exactly, nor how to set up the sniffer to be collecting the neccessary data in a readable manner.

Either:

Can someone point me in the direction of a comprehensive guide to how to collect that data in Fiddler/WireShark

Or

Can someone advise an alternative way to test that the change has worked.

spottedmahn · Answer 1 · 2019-08-14T19:05:58.280

51

If you turn on "CONNECTS" in Fiddler, you can see the TLS/SSL version in Inspectors -> TextView

To turn on Connects, go to Rules in the menu bar and remove the check from "Hide CONNECTs"

Note: Decrypt HTTPs traffic must be disabled

Reference: Viewing HTTPS Handshakes in Fiddler

edited Aug 14 '19 at 19:05

answered Feb 02 '17 at 19:01

spottedmahn

11,379
7
75
144

4

Should be noted that "Decrypt HTTPS traffic" needs to be disabled for this to work. Mentions it in the article linked to, but that could vanish I guess. – superphonic Aug 20 '18 at 13:21
Fiddler doesn't support TLS 1.3, so it can not be checked anyway. – Ali Jun 19 '19 at 07:25

Rich · Accepted Answer · 2015-12-15T11:02:06.557

If you capture the connection creation in Wireshark, and examine the first packet from the client, then Wireshark will annotate the fields in the ClientHello struct for you, including the TLS version requested by the client.

Similarly, if you look at the first reply packet from the server, then Wireshark will annotate the fields in the ServerHello struct for you, including the TLS version settled on for the connection.

See this blog post or this one for worked examples.

score 8 · Answer 3 · edited Mar 17 '17 at 13:14

The System.Net tracing does include sufficient detail to check this, although it's not very accessible.

This KB describes how to turn on System.Net tracing.

This blog post shows a full HTTPS request in System.Net tracing.

The bytes sent over the wire are logged, and in the example given on that blog post, the client stream starts:

System.Net.Sockets Verbose: 0 : [3848] Data from Socket#48285313::Send
System.Net.Sockets Verbose: 0 : [3848] 00000000 : 16 03 00 00 41 01 00 00-3D 03 00 43 26 02 90 83 : ....A...=..C&...

RFC5246 describes TLS 1.2 and explains that ClientHello is the first message expected and states its format:

  struct {
      ProtocolVersion client_version;
      Random random;
      SessionID session_id;
      CipherSuite cipher_suites<2..2^16-2>;
      CompressionMethod compression_methods<1..2^8-1>;
      select (extensions_present) {
          case false:
              struct {};
          case true:
              Extension extensions<0..2^16-1>;
      };
  } ClientHello;

This SO answer explains that the record starts with 0x16 as a type marker, then the protocol version.

The session shown above has version 3.0, which means SSL 3.0.

The RFC explains that 3.3 is TLS 1.2.

So if your client data starts "16 03 03", then your client is attempting to negotiate TLS 1.2.

You may need to examine the ServerHello to establish which version was actually used.

How to test which version of TLS my .NET client is using?

3 Answers3

Linked