Tracking SSL Issues with the SSL Labs API

The SSL and TLS protocols have been on the front of the stage for months. Besides many vulnerabilities disclosed in the OpenSSL library, the deployment of SSL and TLS is not always easy. They are weak cyphers (like RC4), weak signatures, certificates issues (self-signed, expiration or fake ones). Other useful features are mis-understood and not often not configured like PFS (“Perfect Forward Secrecy”). Encryption effectiveness is directly related to the way it is implemented and used. If it’s not the case, encrypted data can be compromized by multiple attacks scenarios. To resume: For users, the presence of a small yellow lock close to the URL in your browser does not mean that you are 100% safe. For administrators and website owners: it’s not because you have a good SSL configuration today  that it will remain safe in the coming months/years. Unfortunately, keeping an eye on your SSL configurations is a pain.

To help us, Qualys offers a very nice tool to assess SSL configurations via the ssllabs.com website. Very easy to use, the website allows you to submit an URL and give you a nice report after a few minutes. The URL is flagged with a grade between “A+” (the best) and “F“. (Note that the worst that I saw until today is “T“). The methodology to compute the grade level is explained in this document. Here is a sample report:

The good news is that the checks performed against the URLs are upgraded when new vulnerabilities are discovered (it was the case with the POODLE attack). You can now understand that your grade at a time “x” can be different at a time “x+y“. That’s why you need to test again your sites at regular interval. The other good news is that an API has been made available for everybody. Check results are returned into JSON data. Such data are not very friendly for the human eyes, that’s why I wrote a few lines of Python to extract useful information:

• The grade (of course…)
• The certificate issuer
• The certificate expiration date
• A MD5 hash of the certificate

The API can be used via a tool called ssllabs-scan. The tool runs on any UNIX flavor (you’ll need “go” to compile it) and reads the hosts to be tested from a flat file:

$ cat sites.txt
registration.brucon.org
www.truesec.be
$ ./ssllabs-scan -hostfile=sites.txt -quiet=true

The small Python script will extract the information listed above from the data returned by the API:

$ ./ssllabs-scan -hostfile=sites.txt -quiet=true | ./ssllabs-scan-parse.py >ssllabs-scan.output
$ cat ssllabs-scan.output
Site: www.truesec.be:443, Grade: A-, CertIssuer: StartCom Class 1 Primary Intermediate Server CA, CertExpiration: Wed Jan 20 04:46:26 2016 CertMD5: 89bd5d0dde1d3ec8a06b192d62ffbb72
Site: registration.brucon.org:443, Grade: A-, CertIssuer: StartCom Class 1 Primary Intermediate Server CA, CertExpiration: Fri Feb 26 01:21:57 2016 CertMD5: da6812d4d43282260d9a4751ed88b908

The last step is to add some automation (because we are lazy people). Create a crontab to run the above command at regular interval (one time a month is enough). Being a fan of OSSEC, I’m just monitoring the result file and any difference will generate an OSSEC alert + notification (ex: if the grade or MD5 changes). Configure a new source in your ossec.conf:

 <localfile>
    <log_format>full_command</log_format>
    <command>cat /data/ssllabs/ssllabs-scan.output</command>
 </localfile>

Create a new rule in your local_rules.xml:

 <rule id="100900" level="9">
    <if_sid>530</if_sid>
    <match>ossec: output: 'cat /data/ssllabs/ssllabs-scan.output</match>
    <check_diff />
    <description>SSLLabs: SSL configuration change detected</description>
 </rule>

Now, you can’t miss any degradation of your SSL configurations, especially of you maintain lot of websites!