TLS 1.2 Implementation Validation

Question

I have a validation question regarding implementation of TLS 1.2.

What tools, scripts, processes, etc.. can be used to validate that TLS 1.2 is working when clients, webserver, and SQL Servers are communicating between each other?

Do I need to perform network packet sniffing, run traces, use process explorer? Is there a verbose option somewhere that can be turned on with logs reviewed?

Note: if it makes a difference, the SQL Servers involved run a variety of versions: 2008R2, 2012, and 2014.

Answer 1

First, see Aaron Bertrand's answer on TLS 1.2 with older SQL Server, and/or Aaron's SentryOne blog post.

If you're talking about the normal SQL Server connection encryption (SQL Server Configuration manager, Force Encrypt yes), with modern SQL Server, then there are two steps:

• select encrypt_option, count(*) from sys.dm_exec_connections GROUP BY encrypt_option
  • If there are any FALSE results, you have unencrypted connections. Fix that.
  • If there are 100% TRUE or NULL results, continue.
• With buy-in from and in coordination with your IT Security team, download Microsoft Message Analyzer, Microsoft's Windows packet sniffer, and watch some connections. You're looking for the ClientHello and ServerHello messages, within which you can see cipher suites offered and which one happened to be accepted.
  • It's a combination of registry and group policy changes to adjust that at the Windows OS level of your SQL Server installations.

---

WATCH OUT FOR THIRD PARTY SOFTWARE

Lots of it does NOT support TLS of ANY kind, much less TLS 1.2, either in the application, or, much more often, during one or more parts of the installation and/or upgrade process. The vendor will be clueless if you ask beforehand, and just as clueless watching it happen in front of them.