Tag Archives: openssl

Verifying Insecure SSL/TLS protocols are enabled

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 install

Doing 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.

Encrypting files with openssl using a password

I needed to send an encrypted file to a user with a Mac. They were unable to install additional software on their machine, and I have no Mac to verify things on.

By default Mac’s roll with openssl installed (thanks Google), so the solution seemed to be to use that.

You can debate the encryption algorithm choice and substitute as appropriate. But the basic syntax for encryption and decryption using AES-256 is shown below:

Encrypt file with password

openssl enc -aes-256-cbc -iter 30 -salt -in report.pdf -out report.enc

Note: running this command will result in a prompt to enter the password, and confirmation.

Decrypt with password

openssl enc -aes-256-cbc -iter 30 -d -salt -in report.enc -out report-decrypted.pdf

Note: again this command will prompt for the password to be entered before extracting.

Warning; running with scissors

This is securing with a password. Go big or risk exposure here. Someone could always try brute force and you want to make sure that takes way way longer than the validity of the information you are protecting. I recommend 72,000 characters long as a minimum to be sure.

Now you have a key distribution problem though. How to get the password to the other person securely? You cannot email them the password since this is the same delivery mechanism for my scenario.

  • Generally WhatsApp (or other end to end encrypted chat client to a mobile phone) is good.
  • Phoning and saying a long password can be awkward but works (so long as they promise to eat the paper they write the password on immediately).
  • SMS is less secure but still verifies that the user is in possession of that person’s phone.

Hope that helps.