Know all About HTTPS CDN, SSL/TLS 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
CDN, 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

1. HTTP/2
2. OCSP Stapling
3. Dynamic Record Sizing
4. ALPN
5. Perfect Forward Secrecy
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
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.

OCSP Stapling
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.

Dynamic Record Sizing

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

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)
Interested in seeing what BelugaCDN can do for your company? Get a free trial and
find out for yourself!
Have feedback? Let @belugaCDN know on Twitter