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.

Desktop Browsers:

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

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 Browsers:

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:

To discuss the information security of your managed cloud services and see how Digital Craftsmen can help you, contact us for a friendly discussion with our experienced team.

Download our information security whitepaper, The Security Mindset, to realise the benefits of information security for managed cloud services.