I work in vulnerability assessment and recently we began to see a series of SSL vulnerabilities related to MS SQL on 1433. While Nessus does have more than its share of false positives, from my experience it is usually pretty accurate regarding SSL.
We have been using MS SQL for well over 15 years, and this is the first I'm starting to see of this, and I'm seeing quite a bit of it. I don't know if it's being set on by default, but I find it odd that only now we're beginning to see these.
Naturally the application teams are all screaming that these must be false positives. I thought it would be pretty trivial to see if SSL was running on 1433, but as is often the case my thinking was a bit off.
I thought I should be able to see this by SSH'ing into one of our Linux scanners, opening two terminals. With one, I set tcpdump up to listen to traffic from one of the impacted SQL Servers. With the other one, I ran the command openssl s_client -state -connect <host>:<port>. I was expecting to see the SSL handshake from openssl in one terminal, and I thought I would also see the SSL handshake in tcpdump/wireshark. This did not happen. Instead, the output from the openssl command didn't even look like it completed a handshake. I don't know, but suspect this is because I didn't go in using something like MS SQL Query Analyzer.
After that failed, I thought I could at least prove my method by setting up the same two terminals, except this time I would be targeting one of our other scanners on its secure port of 8834. The output from the openssl command clearly showed the handshake, but the tcpdump (and tshark) output showed nothing of the SSL handshake. So my thinking was not correct. How would I be able to see the SSL handshake in tcpdump/tshark?
Perhaps more importantly, how can I verify if SSL is even running on 1433 on those MS SQL hosts? The potential vulnerabilities were pointing to certificate errors, yet I was not able to even pull the cert. I tried both the openssl binary and Firefox.
If anyone has any idea on how I might be able to tell with certainty whether those SQL ports - 1433 - are truly running SSL I would be grateful. I would also lover to know where my reasoning went wrong on being able to sniff/capture the SSL handshake.
Here is the output from trying to check the handshake with openssl:
]# openssl s_client -state -connect <host>:1433
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 112 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Any and all help is really appreciated.