Hopefully we all know that we should check for the little green locked padlock symbol in the left hand corner of our browser and the https:// text that both help to indicate that the website we are connecting to in our browser is a) authentic i.e. www.siliconbullet.com is actually the website you asked for (and not a spoofed copy) and b) that the information being passed to and from the website is being encrypted for secure communications.
It is the digital certificate that is applied to the website and the web server (and browser) settings that determine just how secure the communications are; and as we move into a world where every website ought to be using https, there is still more to be done to ensure that we really are configuring our website for secure use.
Free Website SSL Health Check
If you want to check your own website (or someone else’s) https health – Qualsys offer a free web based checking service – that can help you score and appreciate where there may be room for improvement. https://www.ssllabs.com/ssltest
I recommend that you all rush out and check your websites – if you don’t score an A+ contact Silicon Bullet and we can review your website settings/hosting with you.
Whilst the authentication side of the coin is reasonably well understood, it is the encryption side of things that can get very complex. The last few years has seen various flaws such that many of the older encryption standards have been proven to be insecure, and yet many of the web servers in daily use are still allowing the use of these insecure handshakes and protocols, which leaves it possible for man in the middle attacks and other issues to be exploited.
At the start of an encrypted conversation between web browser and server, there has to be negotiation as to what type of encryption is going to be used.
With all the clever handshakes and encryption magic that goes on (that I don’t pretend to fully understand as it quickly gets very complex) – I am aware that for compatibility purposes it is not unusual for the web client and server to negotiate an older, less secure form of encryption; and in fact, this can be used maliciously to force a web client to use an older standard of encryption which in fact does not offer fully secure conversations. https://en.wikipedia.org/wiki/Downgrade_attack
Government agencies such as the NSA in America and GCHQ in the UK and many others may have been exploiting some of the weaknesses to enable eavesdropping on communications that were supposed to be private and secure. And of course that is the “good guys”, there will be plenty of others looking exploit such weaknesses for extortion, infection and other malicious deeds.
Web servers need to be configured to stop offering the older, less secure options, as their default settings or current old settings may still allow poor security options to be negotiated e.g. RC4 cipher, TLS 1.0 ; although there needs to be some consideration of breaking older operating system/browser combinations – as you could be blocking some visitors from seeing your website.
HSTS (HTTP Strict Transport Security)
HSTS is a mechanism to help force web browsers to talk securely to your website before an insecure http conversation can be started.
HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client/browser side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk. Some nice diagrams and additional technical detail can be found on Scott Helme‘s article https://scotthelme.co.uk/hsts-the-missing-link-in-tls/ (thanks for allowing me to link to your article Scott).
Call to Action
Check your website – your company reputation and the safety of your staff and clients accessing your website are all at risk.