In a rapidly changing information security landscape, securing your web communications is no mean feat.
All cryptographic standards provide a degree of security based on current and projected computational power. However, given enough powerful resources, all systems can be broken and rapid advances in computation power and techniques accelerate this process.
In short, cryptography will always be an arms race.
This article will take you through everything you need to know about information security, the different kinds of cryptography available, the different vulnerabilities and how to mitigate them, and best Practices for Securing Web Communications using SSL and TSL.
Ready to secure your web communications? Let’s dive in…
What are the different types of SSL and TLS?
There are five main implementations of asymmetric cryptography in use across the internet. They are SSLv2, SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2.
These implementations are commonly understood to be part of SSL, but there is a difference between SSL and TLS.
All versions of Secure Sockets Layer (SSL) are now widely considered to be insecure and should only be used where legacy applications require its use.
Transport Layer Security (TLS) 1.2 and ‘enhanced implementations’ of 1.0 + 1.1 are now the de-facto method of securing web communications.
The decline of SSL has been accelerated by widely publicised vulnerabilities in SSLv3 in 2014, aka POODLE. Advice from Linux vendors is to turn off SSLv3 whenever possible. Furthermore security researchers are also seeing cracks in early implementations of TLS.
As Adam Langley warns in his article The POODLE bites again:
“This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken.”
What are the vulnerabilities of SSL and TLS?
Encryption is considered cryptographically broken if advancements in techniques or computational power make it feasible to decrypt. Alternative methods of breaking encryption involves influencing selection of key ciphers and creating patterns in cipher text and these techniques continually evolve.
SSL is now considered broken as a result of padding attacks and weak ciphers, consequently SSLv2 and SSLv3 will not be discussed any further. Users of End of Life (EoL) operating systems and browsers are already experiencing issues with HTTPS enabled services and this subset of users is rapidly vanishing.
TLS 1.0 and TLS 1.1 have known issues and those issues are best visualised in the following table. Although there are known issues with these standards; updates designed to mitigate effects have been included within the latest versions of web servers, OpenSSL and browsing software.
To enjoy the assurance of full HTTPS security TLS 1.2 is highly recommended.
Image: Cipher security against publicly known feasible attacks
What is Server Name Indication (SNI)?
Server Name Indication is an integral part of TLS, as the name implies the client specifies which common name it wants to connect to as part of the handshaking process. This allows the server to select the appropriate certificate for the connection.
With the advent of POODLE vulnerabilities, SSLv3 should no longer be in use which has paved the way for the widespread adoption of SNI. The exception is where old clients are required to connect to legacy systems, otherwise all connections should be TLS whenever possible.
What mobile and desktop browsers are SNI compatible?
Older browsers, primarily IE 6, 7 and 8 running on Windows XP, will receive certificate errors when connecting to SNI or TLS only servers. The data on W3schools suggests this will be a subset of the remaining 1.4% of IE 7 and 8 users.
- Internet Explorer 7 and later
- Firefox 2
- Opera 8 with TLS 1.1 enabled
- Google Chrome:
Supported on Windows XP on Chrome 6 and later
Supported on Vista and later by default
OS X 10.5.7 in Chrome Version 5.0.342.0 and later
- Safari 2.1 and later (requires OS X 10.5.6 and later or Windows Vista and later).
- Note: No versions of Internet Explorer on Windows XP support SNI
- Mobile Safari for iOS 4.0
- Android 3.0 (Honeycomb) and later
- Windows Phone 7
Let’s Encrypt and Google HTTPS prioritisation
Let’s Encrypt is another important change and great for development, small and internal websites. And the free certificates it provides also deserve a mention.
Many suggest this is helping to lead the charge of HTTPS adoption, alongside Google who now prioritise HTTPS websites.
10 Best Practices for Securing Web Communications using SSL and TSL
Here are 10 quick ways for your business to secure its web communications using SSL and TSL:
- Do not use SSLv2 or SSLv3
- Be good netizens and use less IPv4 addresses via SNI
- Encrypt to highest standards and practices whilst maintaining compatibility and performance
- Quality Check SSL implementations using third party tools
- Keep abreast of current known good cipher suites
- Use Perfect Forward Security
- Do not use CBC or RC4 Cipher suites
- Disable HTTP and TLS Compression for critical sites
- Provision New Web Servers with Support for TLS 1.2 (nginx & apache 2.4) alongside strong cipher suites
Recommendations for Securing Web Communications
More generally, you should be looking to update machine templates to use newer versions of web servers and OpenSSL.
You should also:
- Define a standard SSL configuration for nginx and different versions of Apache
- Use SNI wherever possible to reduce administrative overhead (and IPv4 usage)
- Incorporate warnings to users of EoL software warning visitors of the risk to their privacy.
If you want to find out more about Secure Web Communications with SSL and TLS, here are some recommended articles:
- Is BEAST Still a Threat?
- Dealing with RC4 Attacks
- BEAST, CRIME, BREACH, and Lucky 13: Assessing TLS in ADCS
- Attacks on SSL whitepaper
- Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
- Time is money (in CBC ciphersuites)
- Strong SSL Security on Apache2
- Cipherli.st – Strong Ciphers for Apache, nginx and Lighttpd
Download our information security whitepaper, The Security Mindset, to realise the benefits of information security for managed cloud services.