The “S” in HTTPS Doesn’t Stand for SSL

Lori Mac VittieDistinguished Engineer and Chief Evangelist

It is natural to assume that when we see a padlock icon in our browsers that the site is using SSL to secure our communications. It’s also apparently a signal to consumers that the site is, in fact, secure. So much so that according to the CA Security Council, 2015 Consumer Trust Survey “only three percent would give out their credit card information to sites without the padlock icon.”

The impact is not limited to consumers. Respondents to our latest State of Application Delivery survey who had already implemented or plan on implementing “SSL Everywhere” had higher confidence (a 3 or higher on a scale of 1 to 5) in their organization’s ability to withstand an application layer attack.

The truth is most people can’t tell you what SSL stands for, let alone describe how it works. What they do know, however, is that it’s a mechanism for ensuring the security of transactions (and thus potentially confidential information) while interacting with an app or web site.

That’s partially our (as in the market’s) fault. We’ve used SSL as a description of both the protocol (RFC 6101) as well as a generic way to describe a secure connection. SSL is the Band Aid of security, the Google of search engines, the Kleenex of tissues.

The reality is that that HTTPS doesn’t actually require SSL. The “S” in “HTTPS” stands for secure, and simply requires some method of securing connections between two endpoints, like a browser and a web site. Increasing, that actually means HTTP over TLS, not SSL.

That’s an important difference because although they share roots, TLS is not SSL is not TLS. They are different protocols, each with their own unique sets of challenges, issues, and impacts. Both secure connections in the same way – they use certificates for authentication and public/private key pairs for encryption – but the implementation differences remain.

Why should you care? You should care because the latest (and perhaps greatest, that remains to be seen) web application protocols (HTTP/2 and SPDY) do not support SSL. They support TLS. They don’t require it, per se, but browser implementations supporting both only offer support over TLS. Not SSL.

Granted, today there’s not a significant number of sites out using HTTP/2 or SPDY, but it is growing. Consider that 7.5% of the top 1000 sites are now serving up content via HTTP/2:

From W3CTech (July 2015):

The new HTTP/2 standard, whose final version has been published in May 2015, is now used by 0.4% of all websites (up from 0.24% at the beginning of the month), and by 7.5% of the top 1,000 sites.

Now consider that we aren’t just talking about browsers and servers. We also have to consider what that means for integration – for the use of APIs coming from some of those top 1000 sites (like Google) that may be forcing the use of not only HTTP/2 or SPDY, but TLS. All of Google’s public services offering encryption use TLS. If you’re integrating some functionality from Google, you might care that they’re using TLS instead of SSL. Because it makes a difference under the hood.

Also note that there are business ramifications. Under PCI, SSL can no longer be used after June 30, 2016. After that point TLS is explicitly required. That means some changes in order to remain compliant with PCI. And of course you do, because if you aren’t compliant there are a whole lotta ramifications. It could, for example, result in higher merchant account fees and fines from the credit card issuers or outright revocation of your ability to process payments and transactions. If there is a breach your business will be at higher risk of lawsuits and fines based on your failure to perform due diligence when it comes to security.

Finally, there’s this very strongly worded RFC (RFC 7568) that spells out why you should really be moving to TLS:

3. Do Not Use SSL Version 3.0

SSLv3 MUST NOT be used.Negotiation of SSLv3from any version of TLS

MUST NOT be permitted.

Any version of TLS is more secure than SSLv3, though the highest

version available is preferable.

Now, it’s not feasible to assume you’re going to run out and switch over from SSL to TLS right this minute. After all, although TLS is based on SSL v3, it is not a 100% backward compatible with its predecessor and it takes some configuration changes to disable SSL and force the use of TLS. Configuration changes that generally require a reboot. In a large environment, this process is, understandably, disruptive and time consuming.

But it is time to start seriously considering how long you want to support SSL and when you want to switch over to purely TLS.

About the Author

Lori Mac VittieDistinguished Engineer and Chief Evangelist

More blogs by Lori Mac Vittie