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 always throw a test rig together to check settings, update settings and get the configuration and the ability to check 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 host 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 screen shot 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 setup 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 also.
More Info:
https://social.technet.microsoft.com/wiki/contents/articles/41703.sql-server-securing-network-communications.aspx
0 comments:
Post a Comment