If a vulnerability scanner tells you that a website supports an insecure SSL/TLS protocol it is still on you to verify that this is true. While it is becoming rarer, there are HTTPS services which allow a connection over an insecure protocol. However, if you issue an HTTP request it will respond to the user with a message like “Weak cryptography was in use!”.
I think this was an older IIS trait. But I am paranoid and in the habit of making damn sure that a service which offers say SSLv3 will actually handle HTTP requests over it. If there is a warning about poor cryptography then the chances are a user won’t be submitting passwords which will reduce the risk.
This blog post explains how to use openssl to connect using specific SSL/TLS protocols. It also provides a solution to a major gotcha of the process; the version of openssl that ships with your OS cannot issue insecure connections.
Using openssl to connect with an old protocol
The best way to do this, for me, is to use “openssl s_client” to connect to the service. The command supports the flags “-ssl2” “-ssl3” and “-tls1” to enable you to confirm those respectively. Say you want to verify SSL3 is enabled on a target you would do this:
openssl s_client -connect <host>:<port> -ssl3 -quiet
If the server supports the protocol it will now say this the line above where your cursor landed:
verify return:1
Your cursor will be paused there because you have established an SSL/TLS connection and now it is waiting for you to enter data.
Issuing an HTTP request through that connection
Having established your connection you will want to issue an HTTP request. A simple GET request should be sufficient:
GET / HTTP/1.1
Host: <host>
This simple request will return the homepage of any HTTP server. The subtle part is that there are invisible newline characters. In truth the above can be expressed in a single line as:
GET / HTTP/1.1\r\nHost: <host>\r\n\r\n
Here a pair of “\r\n” is representing the newlines. The exchange ends with “\r\n\r\n” because HTTP wants a blank line after all the headers are done to indicate when the server should start responding.
To be easier we can use “printf” to issue the GET request directly through our openssl connection:
printf "GET / HTTP/1.1\r\nHost: <host>\r\n\r\n" | openssl s_client -connect <host>:<port> -ssl3 -quiet
If the server responds without warning the user about insecure cryptography then you have just confirmed it as vulnerable.
Major Caveat
Most operating systems rightly ship with secured versions of “openssl”. This means that they have been compiled to not support these insecure protocols. The reason for doing this is to protect users from exploitation! This is good for us. If fewer clients can even talk SSLv3 then how much more unlikely is it that exploitation will occur?
To solve this problem I suggest you compile a version of openssl which has been compiled to support insecure versions:
wget https://openssl.org/source/openssl-1.0.2k.tar.gz
tar -xvf openssl-1.0.2k.tar.gz
cd openssl-1.0.2k
./config --prefix=`pwd`/local --openssldir=/usr/lib/ssl enable-ssl2 enable-ssl3 enable-tls1 no-shared
make depend
make
make -i installDoing it this way creates a local binary (in “openssl-1.0.2k/local/bin”) for you which is not then installed over the system’s maintained one. This keeps your every day “openssl” command in your path secure while giving you the opportunity to confirm vulnerable services.
This solution is adapted from the Gist available here:
For ease I choose to then create an alias for the command as shown below:
alias "openssl-insecure"="/<path>/<to>/openssl-1.0.2k/local/bin/openssl"
I can now call the insecure version by using “openssl-<tab>” to complete with insecure.
Happy insecure protocol verifications to you all.
cornerpirate.com 