We find we are speaking regularly to people to review their currently configured web transport security configuration.
Its one part of the OWASP top 10: to ensure that the data being transported across the untrusted networks of the Internet are adequately encrypted. The configuration of your web server, and the responses you have (possibly mis-) configured it to give out to anonymous users across the internet may be disclosing vital attack information that helps compromise your systems, and at best, shows a lack of strong policy or understanding.
First and foremost, if you’re not using HTTPS, but the plain-text HTTP, then you’re about to get warnings on your site as being “Not Secure”. Its been present on form submission pages for a few months on Chrome, but now that messaging is going out for all unencrypted web pages.
Why not take 3 minutes and visit SSLLabs.com/ssltest and submit the URL of your company web site. Then repeat this for your company’s AD FS or single sign on service, or Webmail service. It will take about 2 minutes on each, and we can thank Qualys for sponsoring this while we wait…
Now scroll down to the first section, “Summary”, and look for any red or orange bars on the page showing some pretty straight forward warnings. You may have a certificate from one of the previously Symantec-operated or owned Certificate Authorities which, although expiring some time in the future, are actually going to stop working for a large majority of users from September. Better action that ASAP!
Next, scroll down to the section that says “Configuration”: if it shows only TLS 1.2 as being enabled, and everything else disabled, you’re probably doing well.But you’re not Done yet.
If you also have TLS 1.3 enabled, then well done (this version is quite new).
But if you have TLS 1.1, or older, then its time to turn that off. And for some of those, that time to turn off was actually back in 2014. But I understand, you’ve been busy.
Now drop a little further to “Cipher Suites”. You should have a note saying “suites in server order preference”, if not, then you should enable that on your server. And finally, ensure you have a “cipher suite” something like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 very near to the top of our ordered list.
Let me break this down:the cipher suite normally goes something like:
The Key Exchange: ECDHE is good, DHE is average, and DH is bad. Get rid of DH and DHE.
Certificate types: depends on the certificate you generated. Most people use 2048 bit RSA based certificates, but longer RSA is possible (and slower), and the newer ECDSA based (elliptical curve) Certificates are coming soon. RSA is fine for now.
Bulk Cipher: Today, AES 128 or 256 (doesn’t matter which) are considered OK. 3DES, RC4 are really bad. Just leave the AES ones enabled.
MAC: If it just says “SHA”, its bad – SHA-1; if it says MD5, then is terrible! SHA256 and SHA384 are both currently acceptable.
Of course, that’s for today. Last week, we could have left CBC based ciphers in there, but then research from Microsoft showed that’s now not considered secure. But in removing the last of the CBC chain mode suites, you’re probably going to stop MS IE 11 from being able to connect.
There’s other tools (Mozilla Observatory), and a lot more places to look — such as the HTTP Headers than can help secure content, and improvements to HTML as well — that should all be reviewed.
Nephology has been securing ecommerce web systems globally, for commercial and government organisations, since 1995 – from the birth of the web. Contact us for more information.