(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.
(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.
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:
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:
Click OK and when you return to the packets you'll see they're now interpreted in more detail:
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: