The evolution of encryption – SSL, TLS and beyond

The momentum for securing more and more web traffic via encryption has been growing at an exponential rate – going far beyond just the requirement to encrypt user credentials for access to content and services. The early part of this decade, saw Google convert its own services - Search, Gmail, etc. to HTTPS only, and announced that it would use HTTPS as an input in its search ranking algorithm. At the time, Google stated its motives were to “make the Internet safer”, which is plausible, as most people around the world access content via a Google search. Users are even being alerted in regards to website encryption, Google’s web browser, Chrome, will flag unencrypted websites as insecure by displaying a red cross over the URL padlock. Increasingly, popular sites such as Facebook and Twitter also took up this cause, leading to the steady penetration of HTTPS-by-default access. The initial cynicism from ISPs and other intermediaries on this trend, based on the belief that such a move was self-serving rather than altruistic as it allows these large players to hide valuable analytics data on user behavior, was overt taken by the Snowden leak and other high-profile revelations of pervasive surveillance of end-to-end communications which helped get the public, both in the US and abroad, generally supportive of an all-encrypted web paradigm.

Google and other major industry players further paved the path towards fully encrypted communications by standardizing the next generation of HTTP, called HTTP/2, which removes major performance inefficiencies identified with HTTP over the years. While HTTP/2 does not require Transport Layer Security (TLS), all browser vendors have chosen to implement HTTP/2 with mandatory TLS usage so that web sites that wish to provide the performance advantages offered by the new protocol must use TLS by default. Growth of HTTP/2 enabled sites show an upward trajectory, currently at about 15.5% including most of the popular web sites.

Thus, by early 2017, at-least half of the worlds web traffic was encrypted, with some estimates having this number higher than 70%. There is data from major browser vendors (Firefox, Chrome) which show that ~50% of web pages loaded using such browsers are now protected by HTTPS. There is one reason for this startling growth in the preceding three years:

Larger players have, the resources needed to make the necessary changes to their backend servers and applications to make HTTPS the default, while smaller players have been helped by various, larger players which provide tools and best practices to help web masters make the necessary conversions. This removes one major excuse for small websites, so that the cost argument can no longer be used to not get on board with the program.

Today, many IP-based protocols, such as HTTPS, eSMTP, ePOP3, eFTP support TLS to encrypt data, which is the successor to SSL (Secure Sockets Layer). However, both these terms are commonly thrown around a lot you might see them both referred to as simply SSL. TLS provides secure communication between web browsers and servers. The connection itself is secure because of the cryptography that is used to encrypt the data transmitted. The keys are uniquely generated for each connection and are based on a shared secret which is negotiated at the beginning of the session, also known as a TLS handshake.

In terms of web performance - TLS and encrypted connections have a lot more overhead than their clear-text counterparts – the more you encrypt the more you can expect performance to be impacted. HTTP/2 has addressed this problem to some extent, and the promise of TLS 1.3 is to help speed up encrypted connections even more. To put it simply, with TLS 1.2, two round-trips were needed to complete the TLS handshake. With TLS 1.3, it requires only one round-trip, which cuts the encryption connection latency in half.

Another advantage of TLS 1.3 is that it remembers sites that you have previously visited, you can now send data on the first message to the server. This is called a “zero round trip.” (0-RTT). And yes, this also results in improved page and application load time times.

In conclusion, it is fair to say that the introduction of HTTPS has led to an exponential rise in encrypted traffic, with almost every web-based application today, and TLS 1.3 is expected to be situated for rapid instruct adoption. This is placing new demands on the network to be able to service these applications effectively and is making it harder for networks to maintain visibility on these applications without companies deploying new solutions that either decrypt or use other mechanisms to allow users to “see” what is on the network.

How do we test to ensure this encryption works?

Today, any number of tests could be run to produce measurable and comparable results for security devices that meet some ideal testing conditions. Unfortunately, there is not an industry organization or regulation that requires vendors to perform a specific set of tests before publishing performance results. However, there are several third-party testing houses that can conduct performance tests on devices. These tests provide a lot more consistency across devices from different vendors, and can produce results that the end consumer can compare during that one test set. It is important to note that it is rather rare for a vendor’s performance claims and those measured by a third-party testing house to be the same. However, these third-party tests are not standardized either, which makes it impossible to compare results from different testing labs, or even the same one over time.

NetSecOPEN is an open standard that enables any vendor, test lab or enterprise to gather useful device metrics of devices that can be compared. NetSecOPEN’s aim is to build publicly available, open and transparent testing standards. These include the test methodology, traffic mixes, and configurations that allow for cross vendor testing, and methods for the comparison of those results.

Not everyone has the time, resources, or ability to do this type of testing. The goal of NetSecOPEN is to give people that ability up front as defined testing methodologies. The NetSecOPEN standards will provide guidelines and best practices for testing modern network security infrastructure. Additional guidance for the interpretation of results will be also created when needed. Spirent is a founding member of the NetSecOPEN industry initiative and more information can be found at www.netsecopen.org.

If you’re interested in learning more about our security solutions visit Spirent’s CyberFlood page. If you would like this level of security expertise for your company and want to speak to our security experts directly, contact us or register for our Cybersecurity live and on-demand webinars.