Overview: I have lost count of the number of TLS upgrades I have worked on. The upgrades are easy as long as you understand the basics. I generally set up a test rig to verify settings, update configurations, and test the traffic.
Understanding Server and Client Registry Settings for TLS:
- "Client" registry keys govern outbound protocol availability.
- "Server" registry keys govern which protocols are available for inbound connections.
The client machine hosts a Console/C# Test Rig that is connecting to SQL Server that supports only TLS1.2. Then, on the client Windows registry settings, you are interested in the TLS1.2/Client/Enabled setting, as shown above.
- Below is a screenshot of a C# test rig, used to ensure the registry settings are correct (I restart the test rig after I make a change to the client/TLS registry settings. Running the "Test Connection", tells me outbound traffic is using TLS1.2, the successful connection tells me that SQL Server is accepting TLS1.2 traffic.
- Wireshark is a great tool, and can be used to verify the underlying traffic, in this scenario I have Wireshark on the client machine to capture and analyze the TLS traffic going to the SQL Server generated by the C# test rig.
- Ensure you have the adapters you want to monitor selected, and I have added a filter to only show traffic being sent to the SQL Server using the IP address. "hosts 10.1.x,25"
Capture the traffic, you'll see the connection being set up in the packet transfer. The protocol will show TLSv1.2 in Wireshark.
 |
| TLS1.2 traffic |
 |
| TLS1.0 Outbound Traffic |
Use Netsh or Pktmon to capture local adapter traffic, then load the logs in Wireshark. c:> netsh trace start capture=yes from the admin run cmd prompt to capture packets. Packet Monitor (Pktmon) is also an option.
tcpdump is a good tool.
More Info:
https://social.technet.microsoft.com/wiki/contents/articles/41703.sql-server-securing-network-communications.aspx
