Everything You Need to Know About HTTPS, SSL/TLS over CDN
With around 40% of the world’s population being connected to the Internet, a single viral link can bring down the entire informational infrastructure of a company. Large, multinational organizations have the resources required to build complex webs of servers spanning multiple continents, to cope with the sudden surge in demand.
But what about small- and mid-sized businesses? How can they compete with established players and still direct most of their resources at the core of their business? The answer is the use of a CDN (Content Delivery Network), a large-scale network of proxy servers strategically located in different locations across the world. Such networks provide excellent response times, high performance, and perfect availability irrespective of the actual physical location of visitors.
In this article, you will learn everything you need to know about the usage of HTTPS, SSL/TLS over CDNs, and some of the ways you can speed up your encrypted connections using technologies such as OCSP Stapling, Dynamic Record Sizing, Perfect Forward Secrecy, and others.
HTTP, HTTPS, SSL, TLS: What’s the Difference?
During the early days of the Internet, there was no single standard through which computers could send hypertext files to one another. This changed in 1989, when Tim Berners-Lee, an English computer scientist, initiated the development of a communications protocol that would become the foundation of the World Wide Web as we know it today. The name of this protocol is HTTP, and its standardization is in the hands of the World Wide Web Consortium (W3C), an international standards organization with more than 400 members.
When HTTP was invented, less than 1% of the world population was connected to the Internet. Most of those who were connected were members of the academia, military, or government. The web consisted mostly of very simple websites that contained only plain text and provided no interactivity whatsoever. As time went on and the technology progressed, people from all over the world became able to use the web for online shopping, Internet banking, personal communication, and business purposes.
A strong need arose for a cryptographic protocol that would enable secure communication over the Internet. The first such protocol was developed by Netscape, an American computer services company that is best known for their web browser called Netscape Navigator, and released as SSL 2.0 in 1995. The version 1.0 was skipped because it contained serious security flaws. The protocol establishes an encrypted connected by a port. In other words, a client connects to a specific port, which is setup to first establish a secure connection and then transfer data.
This—and other things—are what separates SSL 2.0 from TLS 1.0, an upgraded version of SSL 3.0. The first version of TLS was defined in RFC 2246 in January 1999 by Christopher Allen and Tim Dierks of Consensus Development. Although the differences between SSL 3.0 and TLS are not exactly dramatic, the name of the protocol was changed from SSL to TLS (for some interesting history on this change, check out this article by Tim Dierks).
The most notable one is how TLS creates a secure communication over the Internet. All TLS-encrypted connections begin with an insecure handshake between the client and the server. Only when the handshake is successful can the two proceed with the actual exchange of data. Many modern web browsers support TLS 1.1 and 1.2, and, as of July 2016, TLS 1.3 is in heavy development.
This leaves us only with Hypertext Transfer Protocol Secure (HTTPS). The extra ‘S’ simply tells us that data requests are being and received through a tunnel encrypted using SSL or TLS. All modern web browsers indicate HTTPS connection with a green padlock symbol located in the address bar. Visitors can use it to verify the authenticity of the website they are visiting, ensuring their data won’t be stolen by malicious hackers.
Speeding Up Encrypted Connections Over CDN
Even though plain TLS can be used to establish encrypted connections over Content Delivery Networks, there are various extensions which can be used to both speed things up and make them more secure without breaking the compatibility with major web browsers.
HTTP/2 is a variant of SPDY (a Google creation), and was developed by the IETF’s HTTP Working Group — the same group that maintains the HTTP protocol. This new version of the protocol that has served the web for more than fifteen years gets rid of the limitation to one request per TCP connection. In practice, secured websites with a lot of resources can be loaded much faster than they could be otherwise. The practical effects of this can be experienced on every website with on-demand video, including those utilizing Apple HLS & DASH streaming — where the protocol overhead is significant.
Traditionally, when a visitor would open a website secured with SSL, the visitor’s browser would have to contact the certificate vendor who has issued the certificate to verify if it had been revoked. Not only does this take extra time, but it also exposes the identity of the visitor to the issuer of the certificate. With OCSP stapling, it’s the website itself which periodically contacts the SSL certificate vendor and retrieves a time-limited verification of the certificate status. On each new connection, the website sends the time-stamped OCSP response to the visitor. Businesses who use this method can expect higher customer satisfaction, as page load speed is one of the most important factors influencing the abandon rate.
On the internet, all data is converted to packets of information, 1500-bytes or smaller. Browsers and other applications can start parsing and working with information as soon as they receive that data. A browser will typically start to request resources defined in the head of the page before it has even received the whole page from the server.
Browsers, or any application, cannot start decrypting the data until it has fully received the first block of data. If this record is sized larger than one packet, there will be a time window where your client has received encrypted data, but is unable to decrypt it, and in the case of browsers, unable to begin the process of rendering the page and loading other assets (images, style sheets, javascript, etc...). We describe this phenomenon as the latency that TLS introduces. If you have a 16KB TLS record size, and it takes you an extra 1 second to download the complete TLS record, TLS has introduced 1 second of extra latency into your page load. This is obviously terrible for page load times.
This issue is trivial to overcome by simply setting the TLS record size to a very small number, you can in fact even set the TLS record size to be as small as a single packet and reduce the latency overhead of TLS to effectively zero. This, however, introduces a new issue. TLS uses larger records in order to increase performance by decreasing the amount of processing power required for encrypting and decrypting new records. Thus, the performance of larger files suffers greatly with smaller TLS record sizes.
With a bit of care, and some low-level engineering, BelugaCDN has developed a solution that dynamically manages the size of the TLS records to both a) reduce record sizes (thus minimizing latency during the early phases of a request), and b) ramp up record sizes (and therefore throughput) during the later phases of a connection for large file downloads. This combines the best of both worlds: small records early, allowing browsers to start displaying pages and make resource requests sooner, and improved throughput and reduced CPU requirements during the later phases of a connection.
ALPN, and its older cousin NPN, are two standards related to TLS, which allow the server to signify support for protocols other than HTTP when a client makes a secure connection. When a client makes an initial TLS connection they include a list of which protocols the client supports and would like to use to connect. ALPN and NPN are typically used for clients to negotiate support for HTTP/2 on incoming connections.
Perfect Forward Secrecy is a property of secure communication protocols, which ensures that older communication sessions cannot be compromised even in case the public and private keys used in those communications fall into the wrong hands. It increases the overall security of all involved parties and is considered to be a crucial aspect of modern Internet security.
Why You Should Migrate to HTTPS
It’s no secret that Google and other search engines are using HTTPS as one of their ranking signals. In other words, websites that send data over secure communication channels have much better chances of appearing on the first search result page. This, in turn, makes it more likely that visitors will stumble upon your site and not your competitions’.
What's more, HTTPS is a must for every company and website that deals with sensitive information and wants to protect their clients. According to a recent report released by the Identity Theft Resource Center, the number of U.S. data breaches tracked in 2015 totaled 781. That’s more than 2 breaches every single day. If you also take into consideration that “there were 1,966,324 registered notifications about attempted malware infections that aimed to steal money via online access to bank accounts,” according to Kaspersky Security Bulletin 2015, it becomes clear why every extra security precaution matters.
BelugaCDN is one of only a handful of CDNs that support all 5 major TLS extensions (HTTP/2, OCSP Stapling, Dynamic record sizing, ALPN, and Perfect forward secrecy), making it the optimal choice for those looking to secure their assets with HTTPS and accelerate their content delivery. Visit the official website to learn more about services and all the ways it can help you get ahead of the competition.
Author: Adam Jacob Muller, Chief Information Officer (BelugaCDN.com)
