How To Detect SSL Running on a Port

Posted on 2013-11-12
Medium Priority
Last Modified: 2013-12-03

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:before/connect initialization
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
Compression: NONE
Expansion: NONE

Any and all help is really appreciated.

Thank you,
Question by:jpetter
  • 3
  • 2
  • 2
  • +1
LVL 82

Assisted Solution

arnold earned 750 total points
ID: 39643741
The encryption triggering mechanism is initiated by the client.
I am unfamiliar on whether

The fix to your Nessus reported issues applies to the system in its entirety.

The fix is to update the schannel/crypto within the registry that limits to the non-vulnerable ciphers/methods


If you have a firewall with DPI it can detect SSL traffic.
LVL 66

Accepted Solution

btan earned 750 total points
ID: 39644989

Author Comment

ID: 39648994
Thank you both. I have read those articles - actually read most of them prior to posting, and have been using the manual methods with the openssl binary for years. I guess I'm going to have to rethink this. I was looking for a quick way to be able to determine remotely, whether an instance of MS SQL was using SSL or not. Initially I was thinking I could run a packet capture against the MS SQL host, open another terminal and execute an openssl connect against the host on 1433, and be able to see part of the SSL handshake. This will work with many SSL enabled ports where I can see the SSL handshake just from executing something like openssl s_client -state -connect <host>:<port>. This doesn't seem to work with MS SQL - suspect MS is implementing SSL a bit differently.

If either of you have any further ideas, I'd be glad to hear them, otherwise I'll just split the points and move on. This whole exercise was to enable me to tell if the SSL vulnerabilities were valid as I have a lot of app teams claiming this to be a false positive.

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

LVL 66

Expert Comment

ID: 39649751
The ssl should be the same just that it is likely not the openssl. More straightforward is using sniffer either nw monitor or wireshark to detect ssl as the protocol. Even errors will ne surfaced during the sniff if any.
LVL 82

Expert Comment

ID: 39649860
an ssl connection uses encryption hen the client requests it.
it function similar to smtp with TLS (STARTTLS).
openssl s_client -connect mail.somedomain.com:25 -starttls smtp

i.e the unencrypted connection is started, and then they negotiate a secure communication channel within the established connection.
I am unfamiliar with the ms sql trigger to start the tls session.
looked to see what/whether an example exist that could be used with openssl.

Author Comment

ID: 39692310
Sorry for the long time delay. I appreciate your help.

LVL 15

Expert Comment

by:Giovanni Heward
ID: 39693125
I personally prefer SSLScan.  It reports all supported ciphers, preferred cipher preference, and the SSL certificate details.  Any port is supported.

sslscan --no-failed host.domain.local:1433

Open in new window

Testing SSL server cia.gov on port 443

  Supported Server Cipher(s):
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
    Accepted  TLSv1  128 bits  RC4-MD5

  Prefered Server Cipher(s):
    SSLv3  256 bits  AES256-SHA
    TLSv1  256 bits  AES256-SHA

  SSL Certificate:
    Version: 2
    Serial Number: -4294967295
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
    Not valid before: Apr  8 00:00:00 2013 GMT
    Not valid after: Apr  8 23:59:59 2015 GMT
    Subject: / Entity/serialNumber=Government Entity/C=US/ST=Virginia/L=McLean/O=Central Intelligence Agency/OU=Operations 1/OU=Terms of use at www.verisign.com/rpa (c)05/CN=www.cia.gov

    Public Key Algorithm: rsaEncryption
    RSA Public Key: (2048 bit)
      Modulus (2048 bit):
      Exponent: 65537 (0x10001)
    X509v3 Extensions:
      X509v3 Subject Alternative Name:
      X509v3 Basic Constraints:
      X509v3 Key Usage: critical
        Digital Signature, Key Encipherment
      X509v3 Certificate Policies:
        Policy: 2.16.840.1.113733.
          CPS: https://www.verisign.com/cps

      X509v3 CRL Distribution Points:

      X509v3 Extended Key Usage:
        TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto
      X509v3 Authority Key Identifier:

      Authority Information Access:
        OCSP - URI:http://ocsp.verisign.com
        CA Issuers - URI:http://EVIntl-aia.verisign.com/EVIntl2006.cer

Author Comment

ID: 39693192
That's a pretty sweet tool, but while I see you specified port 1433 in your command, the results posted are for 443. What I had found was that most of the tools I used for diagnosing SSL issues are OpenSSL based and didn't give me what I needed when testing it against MS SQL. What I concluded, and probably incorrectly, is that these tools did not work for me on MS SQL as those connections need to exchange a couple of TDS packets that I assumed OpenSSL did not know how to handle. I ended up using Microsoft's Network Monitor for these particular hosts.


Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Ransomware continues to be a growing problem for both personal and business users alike and Antivirus companies are still struggling to find a reliable way to protect you from this dangerous threat.
A new hacking trick has emerged leveraging your own helpdesk or support ticketing tools as an easy way to distribute malware.
Watch the video of Kernel Migrator for SharePoint, which demonstrate the process easily of migration from SharePoint to SharePoint, OneDrive for Business & Google Drive servers, Public Folder to SharePoint, File Server to SharePoint. The tool has va…
In the video, one can understand the process of resizing images in single or bulk. Kernel Bulk Image Resizer is an easy to use tool for resizing large number of images. One can add and resize multiple images with this tool in single go. The video sh…

569 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question