4

I have implemented a secure SSL connection on the SQL Server 2005 server. I use the "Microsoft SQL Server Management studio" to connect to the SQL Server and I check the "Encrypt Connection" check box in the options section. The connection is successful and when I look at the connection properties in the mgmt studio, it shows me "Encrypted=Yes". So that tells me that my SSL setup is correct and I'm able to successfully connect my management studio to sql server on a secure SSL encryption channel.

Question

I want to find out what "security functions" are being used behind the scenes on this connection...because I want to make sure it complies with one of the approved standards by fips 140-2 anex a (http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf), which has information on approved encryption functions

So I used wireshark to capture the traffic and find out the protocols/handshakes. For instance something like 'Auth TLS' request etc...

But I couldn't find out any of the encryption related information (I guess don't know how to). I don't see any SSL protocol packets. Maybe its doing all the encryption stuff at some other protocol level.

So how I do go about figuring this out? I have the packet capture from wireshark and I can provide it to whoever is interested in looking at it. stackoverflow probably doesnt allow attachments.

Any help would be appreciated.

Thanks Amit

FatherFigure
  • 1,135
  • 1
  • 16
  • 39

3 Answers3

3

You want to enter ssl as the Wireshark filter to show only SSL and TLS packets, and you should see the client and server handshake and exchange a list of ciphers. If the client initiates any SSL connection, you should see a CLIENT HELLO somewhere in your capture. You can show only these packets with the filter ssl.handshake.type == 1.

That being said, running SQL Server 2005 SP1+ in FIPS 140-2 mode is covered by KB article 920995. From what you wrote, it sounds like you are just hoping the client and server pick an allowed cipher, but that's not how FIPS 140-2 works. Even if your session chooses an allowed cipher, it may not choose a FIPS-certified cipher, and the certification is what's important.

The KB article spells it out with this quote:

Note that it is not sufficient to use an algorithm from the approved lists in FIPS 140-2. It is necessary to use an instance of such an algorithm that has been certified.

To guarantee the server uses a FIPS-certified cipher, you need to enable the FIPS 140-2 policy like the KB article says.

indiv
  • 17,306
  • 6
  • 61
  • 82
  • @indiv : I entered ssl in the search field of wireshark. I am able to view the handhshake process and the encrypted data etc. But I am not able to view the encrypted key during keyexchange. How can I view the encrypted key(during the procees of key exchange 252 - client key exchange) in wireshark? – Ashwin Apr 20 '12 at 06:55
0

not using wireshark but using netmon, i have a write up on doing this here: http://cornasdf.blogspot.com/2010/04/sql-server-data-in-transit-cipher.html

cornasdf
  • 131
  • 5
0

Using Wireshark, you can easily find whether the connection is encrypted by looking at the packet data. This document explains the analysis clearly => https://middlewareworld.org/2020/09/04/step-by-step-ssl-handshake-with-wireshark/

Brian Adams
  • 1