UNIX Consulting and Expertise
Golden Apple Enterprises Ltd. » Page 'OpenSSL tricks – checking https ports'

OpenSSL tricks – checking https ports

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

Checking whether or not your web server is running is pretty simple – telnet to port 80, issue a HEAD request, and make sure you get a valid response. What’s less well known is how to test an https session – in this post I’ll go through the nice tool the OpenSSL toolkit gives us.

People think of OpenSSL as a collection of libraries that enable us to build in SSL support to a variety of things – webservers, LDAP servers, etc. OpenSSL also happens to be a toolkit in binary form that’s built along with the libraries, and it’s a pretty powerful bit of kit.

First of all, we can use the s_client functionality to test an https connection:

bash-3.2$ openssl s_client -connect www.siliconbunny.com:443

depth=0 /C=GB/ST=Berkshire/L=Crowthorne/O=Silicon [email protected].com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=GB/ST=Berkshire/L=Crowthorne/O=Silicon [email protected].com
verify return:1
Certificate chain
 0 s:/C=GB/ST=Berkshire/L=Crowthorne/O=Silicon [email protected].com
   i:/C=GB/ST=Berkshire/L=Crowthorne/O=Silicon [email protected].com
Server certificate
subject=/C=GB/ST=Berkshire/L=Crowthorne/O=Silicon [email protected].com
issuer=/C=GB/ST=Berkshire/L=Crowthorne/O=Silicon [email protected].com
No client certificate CA names sent
SSL handshake has read 1630 bytes and written 316 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 80F355438981C329BEF0BB1CCA4936906EE0A0F71C0B7AD4A873629081E7452A
    Master-Key: BD04DC16B134FBB2B5F5833FEB72853245EC060536AD6F4A6FEBA7DFD47F607693795F9CE3B1F291593E489B685FAE70
    Key-Arg   : None
    Start Time: 1260328910
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)

This allows us to form a proper SSL connection to the web server – we can see the certificate, check it’s validity, and then run our HEAD request check as well. We’re not just doing a basic “are you listening?” check – openssl is forming the same https connection a client would, so this is very handy when checking out certificate mis-matches or bizarre client errors.

Within the same session we can then start talking http and check our server is doing the right thing:


HTTP/1.1 200 OK
Date: Wed, 09 Dec 2009 02:02:43 GMT
Server: Apache
X-Pingback: http://grond.gaeltd.com/xmlrpc.php
Cache-Control: max-age=0
Expires: Wed, 09 Dec 2009 02:02:43 GMT
Vary: Accept-Encoding,User-Agent
Connection: close
Content-Type: text/html; charset=UTF-8


Worst case you can do this testing direct on your web server, but pretty much most machines should have OpenSSL installed, and at a minimum you should look at adding it to your collection of tools on your laptop or memory stick.

Another interesting and lesser known use of OpenSSL is for file encryption.

This is an example using OpenSSL’s enc function to encrypt a text file using the Blowfish cipher:

bash-3.2$ openssl enc -e -a -salt -bf -in testfile.txt -out testfile.blowfish
enter bf-cbc encryption password:
Verifying password - enter bf-cbc encryption password:

You’re prompted twice to enter a password to be used, then OpenSSL will encrypt the file for you.

Decrypting a file is very similar – calling the enc function in decrypt mode (-d) and changing your input and output files:

bash-3.2$ openssl enc -d -a -bf -in testfile.blowfish -out tomcat-testfile.txt
enter bf-cbc decryption password:

Using OpenSSL like this for file encryption gives you simple, easy access to quite strong encryption algorithms, but without the hassle of managing key files that you get with PGP – so can be an ideal solution for things like managing sensitive webserver log files.

The last OpenSSL trick to look at is hashing functions – specifically we want to calculate a message digest to check that a file hasn’t been tampered with.

Although outdated md5 is still the most commonly used hash function to check a file’s integrity – most often you’ll be looking at md5 checksums to verify a large file has been fully downloaded, or that it’s not been tampered with.

All we need to do is call OpenSSL with it’s digest function, specify the hash algorithm to use, and then give it a file to check. Classic case here – I want to verify that the checksum for the VPN software I’ve downloaded matches up:

bash-3.2$ openssl dgst -md5 -c Tunnelblick_3.0b22.dmg 
MD5(Tunnelblick_3.0b22.dmg)= 5b:d3:6d:2a:06:22:9f:58:00:01:f8:e1:15:48:7c:d9

Although md5 is the most common hash function in use, it’s considered outdated and has been deprecated in favour of stronger functions like SHA-1 – which are just as easy to use via OpenSSL:

bash-3.2$ openssl dgst -sha1 -c Tunnelblick_3.0b22.dmg 
SHA1(Tunnelblick_3.0b22.dmg)= 7f:56:1c:96:68:4a:fc:b3:f6:27:99:11:41:89:ed:7e:30:97:28:7f

Hopefully this has given you an idea of the power and flexibility of the OpenSSL tookit. A big advantage of utilising OpenSSL in this way is that it can easily be scripted, given you some very powerful tools for carrying out simple sanity checks on remote, publicly accessible servers.

Like this post? Spread the word!
delicious digg google
stumbleupon technorati Yahoo!

Comments are closed.

Top of page / Subscribe to new Entries (RSS)