Using Wireshark, I am trying to determine the version of SSL/TLS that is being used with the encryption of data between a client workstation and another workstation on the same LAN running SQL Server. Documentation on this subject suggests to look at the ServerHello and ClientHello messages but I cannot see any such messages in the Wireshark message feed. I am using this display filter:

tcp.len>1 && tcp.port==1433

I can confirm that encryption of data is occurring and that the packets displayed using the above filter are related to the SQL Server data transfer that I am wanting to examine. This is what the Wireshark message feed looks like:

enter image description here


Here is the packet details pane of the 4th packet after invoking a database connection and selecting Follow-->TCP Stream:

Packet Details Pane

This is what I see when analyzing using Microsoft Message Analyzer. The TLS details pane is for the Client Hello packet.

Microsoft Message Analyzer Main Pane

Microsoft Message Analyzer TLS Details Pane

  • It should be in the Hellos. Can you confirm that you have the initial handshake packets?
    – schroeder
    Nov 18, 2016 at 8:25
  • What I have posted in the image above is all I can see.
    – Guru Josh
    Nov 18, 2016 at 8:27
  • Is there something else I need to include in the display filter?
    – Guru Josh
    Nov 18, 2016 at 8:27
  • 1
    Can you filter for all packets that comprise the TLS handshake ssl.handshake
    – cyzczy
    Nov 18, 2016 at 9:01
  • 2
    If possible please share the pcap. You can't find the ssl handshake in Wireshark using the ssl filter as the TDS protocol uses SSL/TLS internally using SChannel(Windows internal implementation of SSL/TLS). You need to go through the structure of TDS protocol mentioned in TDS protocol documentation.
    – ifexploit
    Nov 18, 2016 at 12:12

3 Answers 3


(Adding a new answer which should be definitive, leaving the old around as it's useful debug for how we got here. Credit for pointing to the actual answer in comments goes to @P4cK3tHuNt3R and @dave_thompson_085)

Using Wireshark, I am trying to determine the version of SSL/TLS that is being used with the encryption of data between a client workstation and another workstation on the same LAN running SQL Server.

You are viewing a connection which uses MS-TDS ("Tabular Data Stream Protocol"):

...the Tabular Data Stream Protocol, which facilitates interaction with
a database server and provides for authentication and channel encryption
negotiation; specification of requests in SQL (including Bulk Insert);
invocation of a stored procedure, also known as a Remote Procedure Call
(RPC); returning of data; and Transaction Manager Requests. It is an 
application layer request/response protocol.

If you view the TDS protocol documentation, it specifies that the SSL packets are encapsulated within a TDS wrapper:

A TLS/SSL negotiation packet is a PRELOGIN (0x12) packet header encapsulated
with TLS/SSL payload.

In the Microsoft Message Analyzer screencap you posted, we can see the TDS header (boxed in Red, starts with 0x12), followed several bytes later by the TLS CLIENT_HELLO packet (boxed in Blue, starts with 0x16 0x03 0x03):

TDS and encapsulated TLS headers

  • 0x16 is the TLS "Handshake" header indicator,
  • 0x03 0x03 is the TLS version (TLS 1.2, as per RFC 5246):

    The version of the protocol being employed. This document describes TLS Version 1.2, which uses the version { 3, 3 }. The version value 3.3 is historical, deriving from the use of {3, 1} for TLS 1.0.

So the simple answer to your question, "determine the version of SSL/TLS", is "TLS 1.2".

Now, I've seen varying reports as to whether Wireshark can properly parse TDS packets with encoded TLS. I think that the answer is what you started with - it will tell you TLS is there, but won't parse the details as it would with a native TLS session.

As per this StackOverflow question, it appears that Microsoft Network Monitor is capable of parsing both levels of encapsulation. And a comment therein states that Microsoft Message Analyzer is the newer equivalent of that tool.


I just use this filter in Wireshark to find TLS 1.0 traffic:


0x0302 is TLS 1.1 and 0x0303 is TLS 1.2.

  • How did you figure out that TLS 1.1 is 0x0302 and TLS 1.2 is 0x0303? Is it documented somewhere or did you check for both and observed it. May 28, 2021 at 4:24
  • 1
    This is indicated as deprecated by my version of Wireshark, is there an up to date alternative?
    – Panki
    Nov 11, 2021 at 11:51

(Ignore this answer, which I'm leaving for historical data, and read my other answer, which explains what's actually going on)

Update after an example packet was added to the question -

The packet you've provided is clearly not a TLS packet. Looking at the hex you've provided, the first three octets of the TCP data are 12 01 00, but for a TLS packet the first three bytes should be 16 03 0X, where 0x16 means TLS "Handshake" record type, 0x03 means SSLv3/TLSv1.*, and the 0x0X indicates the TLS version - 0x01 for TLS 1.0, 0x02 for TLS 1.1, and 0x03 for TLS 1.2.

Additionally, there's a cleartext "sqlexpress2012" string in the packet, which wouldn't be there if this was a TLS Client Hello.

Marked up copy of provided packet

(How did I decide 12 01 00 was the beginning of the data? The first 14 bytes of the packet are the Ethernet header. The next 20 bytes are the IP header. The 13th byte of the TCP header is 0x50, and the first nibble of that byte times 4 is the TCP header length, so 5*4 = 20. So the first bytes of actual data start 54 bytes in at 12 01 00 6c 00 00 ...)

So if Wireshark won't display this as TLS, that's because it isn't. You should revisit your server configuration.

Original answer:

Because those packets are not on a standard TLS port (e.g., 443) you need to tell Wireshark to interpret them as TLS packets. By default port 1433 is not interpreted as having TLS; the default for TDS is to be unencrypted. So by itself Wireshark will not parse it as TLS:

Wireshark default decoding for port 1433

In order to change this, right-click on one of the packets and select "Decode As". Make sure the port "value" is set to 1433 and then set "Current" to SSL:

Wireshark "Decode As" dialog

Click OK and when you return to the packets you'll see they're now interpreted in more detail:

Packets with SSL decoding turned on

Finally, if you look at the detail pane for one of the packets (I suggest using the server hello, not the client hello, in case protocol was adjusted) you'll see the TLS version quite clearly:

Packet detail showing TLS version

  • After doing that, I am not seeing that level of detail and I am not seeing a Client Hello or Server Hello packet. However, the Protocol column now displays "TLSv1.2" for every packet. On connecting to the server, I am getting a series of packets with Info "Ignored Unknown Record". When I bring up the details pane for those packets, the "Secure Sockets Layer" node does not display the TLS version details as per your screen shot. I take it though that the Protocols column is giving me the correct information that I require?
    – Guru Josh
    Nov 18, 2016 at 22:22
  • @GuruJosh at this point I'm wondering if your traffic is really TLS like you think it is. Can you filter onto a single connection (tcp.stream eq 0, for example), double click on the 4th packet (first data packet after TCP 3-way handshake), and update your question with a screenshot of the bottom pane ("packet bytes")?
    – gowenfawr
    Nov 21, 2016 at 13:25
  • Exactly which display filter should I apply? If I apply the filter "tcp.len>1 && tcp.port==1433 && tcp.stream eq 0", this doesn't show any packets even when I invoke a database connection between server and client. If I apply the filter "tcp.stream eq 0" then the message feed gets contaminated with an ongoing stream of other packets and I can't distinguish which ones are invoked by a database connection.
    – Guru Josh
    Nov 21, 2016 at 16:07
  • If it provides any kind of clue as to what is happening, if I disable TLS 1.2 then where the Protocols column was displaying "TLSv1.2", it is now displaying "TLSv1.1". Also I can confirm that the traffic is encrypted because when I remove "Encrypt=True" from the connection string, I can see plain text SQL on the right-hand-side of the packet bytes pane.
    – Guru Josh
    Nov 21, 2016 at 16:09
  • 1
    As a leeter correctly commented on the Q, SqlServer wraps TLS inside TDS, which is the protocol SqlServer (and Sybase before it) uses for everything, so you won't ever find the TLS header at the beginning of the TCP body. There was a Q on this recently (but I can't find it) where someone told me Wireshark v2 can decode this; the last time I had occasion to try was before v2 came out, around v1.6 or so, and that did not. Nov 22, 2016 at 8:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .