In building the new version of our HunchLab product for crime forecasting we are very concerned about security.  Police departments work with data sets that not only require privacy but can also expose individuals to harm if the data is disclosed publicly.  As application developers we often focus on security within the data center.  While making sure that our application properly handles SQL injection attacks and maintains the proper firewalls is critical, the weakest security component is often the client themselves.   Here are a few tips to improving your application’s security outside of the data center.

SSL is not so simple

When we browse the web, we know that when we see the lock icon in the browser tab our communication is encrypted and therefore “secure”.  But not all TLS/SSL is actually secure.  In researching the topic for our development work, I encountered quite a scary reality.  More than 20% of websites support a version of the SSL protocol that is completely broken (SSL v2).  So what to do?

TLS 1.0 is supported by nearly all browsers — a notable exception is Internet Explorer 6.  If you can live without IE6 support (and I pray that you can) then there is no reason to support SSL version 2 or 3 in your application.  You should also enable TLS 1.1 and 1.2 for browsers that support these newer standards.

If you are operating a highly sensitive application and can control which browsers you support, then disabling TLS 1.0 and selecting the right options can also improve security.  I found the cipher chart and browser support charts on Wikipedia to be immensely helpful.   For HunchLab 2.0 we decided to only support TLS 1.1 and 1.2 since we are dealing with sensitive data.

These newer version of TLS give you the option of supporting ciphers with forward secrecy.  For instance, assume you have typical SSL settings turned on and the NSA logs all of the traffic to your website.  Perhaps they can’t decrypt the traffic today, but if at any time in the future they get a copy of your private SSL certificate key, then they can decrypt all historic traffic.  Forward secrecy prevents this issue by generating ephemeral keys for each connection.  Look for settings for ephemeral Diffie-Hellman (DHE) and elliptic curve Diffie–Hellman (ECDHE).

A great way to learn about these settings and see how your application does is to use this SSL Tester.

HTTP Strict Transport Security

Another way to improve security is to tell the user’s web browser to only use encrypted connections.  This is really easy to do via the HTTP Strict Transport Security (HSTS) response headers.  If you support SSL within your application for all URLs then there is no reason to wait to do this.  It’s a simple header.    Chrome, Firefox, and Opera currently support this standard.

Tips:

• Support only TLS 1.0 or newer (TLS 1.1 or newer if you can)
• Turn on TLS 1.1 and 1.2 and configure forward secrecy
• Enable HSTS to force browsers to use HTTPS