In padlocks we trust

Why HTTPS does not carry the meaning any more it once did

As of October 2021, about 90% of sites are presumably on encrypted HTTPS connections, safeguarding your data in transit against curious third parties. That wasn’t always like that.

Credits: William Eickler

In the beginning there was plaintext

Most of the original RFC protocols were designed without encryption in mind and send data in plaintext over the network. Albeit not ideal, it was originally not necessarily an immediate problem as the Internet was a relatively homogenous place at that point, where many people even knew each other and where abuse was less of a common thing than these days.

As it became more popular, so did abuse and in the 90s people realised some sort of innate encryption will be necessary. This was when SSL was born. A couple of years later it was renamed to TLS, to help Microsoft save face, and received every couple of years an update in the form of a new version where some ciphers were deprecated and new ones introduced, but its overall concept stayed the same and it was adopted by many application protocols as encryption tunnel/layer to add security to previously unencrypted protocols.

23 years till 50% SSL, and still not there ....

HTTP, the lingua franca of today’s Internet, was one of the early adopters of SSL/TLS, with Netscape already securing it in ‘94 in the first version of their browser Navigator — welcome HTTPS.

While HTTPS support has been present in virtually every browser since then, it should still take another 23 years until at least half the traffic on the Internet was actually using it. A lot of that had to do with the following three reasons

1. Certificates were often quite pricey
   Very much like domains, SSL certificates were considered a proper cash cow which was to be milked. Even though there were (and still are) pretty reasonably prices certificates at around ten dollars a year, there still are quite a few rather pricey example of several hundred dollars as well. Free alternatives (starting with StartCom in 2005) are still often “ignored”.
2. SSL did add a performance overhead
   Often the argument against encryption was (and still is) the additional layer of complexity and computation. While true at the beginning, it now is not more than a common myth.
3. People like security, as long as they don’t have to maintain it themselves
   Certificates simply require additional work, expertise, and maintenance.

These were reasons good enough for most sites to ignore SSL, respectively, only offer it if deemed really necessary (e.g. in financial contexts).

Certain web technologies even require an encrypted connection

Towards the mid-2010s the attitude began to change and people were made more aware of security aspects in the context of unencrypted sites. This was partially because of Let’s Encrypt, which started offering free certificates in 2014 and had received a lot more media attention than its 2005 predecessor StartCom, but also thanks to browser vendors which started to put a stronger emphasis on encrypted connections. Certain web technologies even require an encrypted connection. With all that PR and browsers pushing for SSL, encryption finally made it mainstream and sites started to move to HTTPS.

At the beginning of August 2017 the Internet eventually had more than 50% of sites on SSL and by now (October 2021) we are at about 90% and HTTPS is considered standard and expected these days.

And they encrypted happily ever after ....

All good!

Or so they thought

One would think that communication on the Internet should be pretty safe if the vast majority of sites uses proper and modern end-to-end encryption and securely transfers every byte from your browser to the server, right?

You haven’t reckoned with reverse proxies, have you?

In the good old days, when you sent a request that request usually made it directly to the server in question. Larger sites possibly had some internal routing or load balancing, but that was pretty much it.

Fast forward to the era of reverse proxy services

There are plenty of services out there which promise to improve a site’s security and performance. Three of the larger ones are

• Cloudflare
• Fastly
• Sucuri

They offer plenty of features in this context, CDN, DoS protection, caching, firewall, you name it. Though, what they have in common is, at the core of their service, they run a reverse proxy which tunnels a site’s traffic through their system, analyses it, mitigates potential attacks, applies defined security rules, and eventually forwards everything to the actual server. Apart from potential privacy or data implications it does sound like a pretty sweet deal, doesn’t it?

The problem is, all three support an encryption breaker feature which renders the whole idea of SSL pointless.

• https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes#flexible
• https://docs.fastly.com/en/guides/working-with-hosts#editing-a-host
• https://docs.sucuri.net/website-firewall/configuration/ssl-mode/#partial-https

What it comes down to is that — like any reverse proxy — they do not just tunnel network packets but actually receive the request, process it, and then send it as a separate request on to the actual server. In that last step they have full control over what and how they send and can, for example, tweak many parameters of the connection, among them the encryption level — that’s the issue.

Out of those three service providers, Cloudflare has — thanks to its free plan — the largest market share and serves millions of sites. For that reason we will focus in the following example on their service, but the issue itself is not limited to Cloudflare.

Let’s show some flexibility

Cloudflare offers four modes for connecting to the origin server

1. Off
   Straightforward HTTP everywhere. HTTPS requests get redirect to HTTP.
2. Flexible
   Accepts HTTPS requests but downgrades them to HTTP when forwarding the request to the origin.
3. Full
   Does not downgrade HTTPS connections, however disables certificate validation and accepts invalid server certificates as well.
4. Full (strict)
   The only mode where a properly secured HTTPS connection is used and the server certificate validated.

Enterprise plans support a fifth option, which actually always enforces SSL

Even though Off does not come with any encryption at all it is not a security issue per se, as it simply is a standard, unencrypted HTTP connection which the browser will be aware of and which it will make obvious to the user. Nothing hidden, just a regular site on plain HTTP.

Full (strict) is fine as well. Cloudflare will use a properly validated HTTPS connection to the origin and require a valid certificate just like a browser would do.

The issue, now, is with Flexible and Full. As the name would suggest, Full is still relatively similar to Full (strict) and an SSL connection will be used to communicate with the origin server. The major difference is, it will not verify the certificate but, instead, accept any certificate it gets presented. This is the perfect occasion for anyone who has adequate network access to perform an MITM attack.

All of which without the the visitor knowing a thing, because he’s only dealing with the certificates on the proxies, which are perfectly valid of course ....

If you think this is a bad idea, just wait a moment because Cloudflare has yet one more encryption mode up their sleeve.

Welcome to Flexible!

With Flexible, the proxies won’t even think of using encryption but will go straight for HTTP, regardless of whether the original request was encrypted.

If you can’t yet fully imagine what that means, think of it as if HTTPS vanished from the face of the earth and everything was back on HTTP. Your login data, your financial information, your messages, your orders, everything you send across the Internet to a site is not sent any more securely over an encrypted connection but in good, old 90s fashion. Anyone who has remotely access to any of the network sections between the proxy service and the origin server can not only perform MITM attacks but also passively monitor and eavesdrop on requests. That includes, but is not limited to

• law enforcement agencies
• peering providers
• the host of the site
• other customers who host in the same network

The WTF

What these services provide is essentially undoing what security experts have advocated for decades, what bodies like W3C have made standards for a reason, and what browser vendors have worked hard on to get out to people — proper, secure, and reliable end-to-end encryption.

The Justification

It’s not uncommon to come across arguments of the sort of “it’s not that bad for sites where one doesn’t need encrypted content” or that “it’s better than having no encryption at all” or that “only the first leg of the request is relevant and needs to be secure”. These are all rather poor attempts of providing a justification and finding an excuse for a broken system.

Sure, not all sites need transport encryption. If we leave the aspect of tampered data aside, there’s definitely content which can go without being encrypted. If I have a landing page where I am just advertising my newest book, one can easily argue that this won’t need to be encrypted. Same, certainly, goes for a lot of typical blogs. The argument, however, does contradict itself. If content does not need encryption, then — well — it does not need encryption 🤷🏻‍♂️.

Another popular argument is that it’s only important to have the first leg secured, because some places (hotel, cafe) might have insecure setups and everything past them is secure. Would this imply it’s perfectly safe to do everything on HTTP on my home connection because I know that setup is safe?

How much the 90% HTTPS traffic really is on HTTPS

Then, of course, there are also the more ludicrous (and just slightly unrelated) arguments of the sort that “it actually does not matter as you can’t tell how secure the server itself is”. Does this suggest we don’t need TLS at all? The T in TLS is actually a strong hint on what scope it tries to cover.

The Impact

If it really was just the occasional blog or landing page we could probably ignore the issue as a whole.

Problem is, it’s not just an occasional blog or landing page. These services are used massively and millions of sites rely on them to front their non-SSL sites with an SSL smoke screen. Cloudflare alone has 25+ million domains under their management and data suggests that at least 30% of them use an insecure mode. That’s a double digit in millions of sites which appear to be secure but are actually not.

And that’s only Cloudflare, add the other providers mentioned earlier and we won’t even know how much of the 90% HTTPS traffic really is on HTTPS up to the server.

The 🍒 On The Cake

Visitors have no idea of that and have no way of finding out either. To them those sites appear as secure because the browser will show the famous SSL badge (or, more recently, at least not yell insecure). These setups keep visitors and origin server well apart and don’t provide feedback on the security of the connection to the origin server.

If you are opening such a site, you can be happily typing your password in a seemingly secure HTML form and it all still gets sent over the Internet in good old plaintext.