Mitigating POODLE on MS SQL Server
Posted on 2015-02-24
We have some Windows 2008 R2 servers that have had SSL completely disabled via the MS recommended registry change, and the subsequent Nessus scans bore that out as 443 was no longer being flagged for SSL POODLE.
However, the MS SQL Server running on the same host does still flag that vulnerability during the Nessus scans. I don't seem to be able to get good results using the openssl binary or sslscan to check out the SQL Server port. I also attempted logging into the SQL Server using sqlcmd while running a capture with NetMonitor, and the output would lead me to believe it is not running. Looking at the capture output, I can see where the client attempts a TLS handshake with the client hello, and then there is a client key exchange, followed by an TLS application data packet. Those are the only TLS packets - there were no TLS packets from the server responding to the client so I would think that would indicate TLS/SSL is not being used by the SQL server.
BUT - why would sqlcmd attempt to initiate a TLS handshake if encryption was not enabled, and Tenable states this is not a false positive.
Can anyone help me clear this up. Is there a good, definitive method to determine if SSL is enabled on MS SQL Server? This is assuming SQL Server does not use the system wide SSL/TLS implementation.