TLS, sometimes referred to as HTTPS, is often held up as being very important for privacy reasons. In most cases that is true, but there are exceptions. And blindly arguing for every website to use it without understanding the wider implications also carries its dangers.

As promised, I’m delivering a second episode of The Private Citizen to you this week to tide you over until I’m back from my holiday.

Today, I want to talk about TLS and some common misconceptions about this technology, especially when it comes to privacy. Before we get into this topic, I would like to say that it is very important that you actually listen to everything I’m saying here. Listen to the whole podcast before you start reacting. Many of these misconceptions exist, because people only read headlines or listen to a part of an argument. If we want to have an intelligent argument, we need to hear each other out.

Hyperbole and name-calling, like labelling people “HTTPS Anti-Vaxxers”, doesn’t help anyone. Vaccination is an idiotic analogy for TLS encryption and even using that term makes you look dumb to people who understand both topics. Please, just listen to people’s arguments and deal with the facts laid out before you. Try to resist undue emotion and knee-jerk automatisms.

What TLS Does

TLS or Transport Layer Security, sometimes referred to as SSL or (more generically) as HTTPS, is a protocol designed to encrypt traffic flowing between your web browser and a server you’re pulling data from. It has three main goals:

  1. Make it impossible for anyone aside from you and the people having access to the target server to see the data you are exchanging with that server. This is often simply called “encryption”.
  2. Assure you that nobody can mess with the data being exchanged over the connection; i.e. the data you are seeing is the data that was originally sent by the server. This is called “message integrity”.
  3. Provide you with reasonable confidence that throughout your communication with the server nobody is stealthily reconnecting you to someone else or inserting themselves in the chain of communication. This is referred to as “authentication” or sometimes “protection against man-in-the-middle attacks”.

With TLS in place, someone connecting to a web server enjoys a number of privacy and security benefits that aren’t available on an ordinary HTTP connection. This is most important for dynamic websites, where the user sends data to the server – like login credentials, passwords or confidential messages that aren’t meant to be read by the public internet.

Without TLS, your login information (including the password) might be intercepted when you’re logging into a website – for example if you’re doing so in an unsecured WiFi environment. It would also be possible to exchange a file you requested for another one, thus sending you malware or other bad things.

→ Wikipedia: Transport Layer Security

Snowden teaches us that intelligence services like the NSA are recording data flowing through the internet en masse. Anything that isn’t encrypted – most often that would be TLS encrypted – can be searched, indexed and used for all kinds of nefarious purposes by these agencies. It is therefore a good idea to encrypt as much web traffic as possible, for the good of all web users.

However, it is important for people to understand that TLS isn’t a magic bullet that will solve all our privacy and security problems. And sadly there are a lot of misunderstandings und false blanket statements out there when it comes to this topic.

Common Misunderstandings about TLS

Because of the Snowden revelations, and because of the resulting good cause of making sure all web traffic is encrypted, a number of people randomly rail against admins who don’t use TLS on their websites. There are two blanket statements you hear again and again: TLS is more secure and TLS is essential for privacy. Let’s examine these.

TLS is More Secure

While it is true and very important that TLS prevents login data from being compromised and also prevents attackers from changing the data in the connection and potentially sending you malware, the fact that a website gets served over HTTPS has nothing to do with how secure it is. In fact, the introduction of Let’s Encrypt has made it much easier for malicious sites to be served over HTTPS.

TLS is there to assure you that the connection to a website is more secure. It has no bearing on the security of the actual server you are connecting to.

Sadly, many people don’t understand this. To a large part, this is the fault of the browser makers who have, with their UI design, taught people that “HTTPS means secure”. Browsers have largely gotten rid of the green padlock, but they are, by and large, still insisting that websites that aren’t using TLS are “unsecure”. Which is simply wrong. The connections to those websites are unsecure. Scammers will happily serve you unsecure malware from a very unsecure website over a very secure connection these days. It is vital that people understand the differences here.

TLS is Essential for Privacy

Privacy is a big part of why TLS exists and it can be very important to protecting your privacy online. But for many website use cases, there are much more important factors impacting the user’s privacy than if the connection to the server is encrypted or not. Of course, if your password gets snooped over an unencrypted connection and an attacker can log into a website where you uploaded confidential information, all privacy goes out the window. This is more a matter of authentication security – that can nonetheless have a profound impact on privacy.

But just like the security argument, TLS alone doesn’t guarantee privacy. You can have very well encrypted connections to a website that embeds third-party code that leaks all kinds of information about you. This information can be sent over TLS-encrypted connections, but that hardly matters. Because your information is still leaked to a third party. In many cases these third parties are the worst privacy offenders on the web – like Facebook or the army of ad-networks that belongs to or works with Google. What you have then is a website that heavily invades your privacy over a secure connection. But your privacy is still being invaded.

Tracking Scripts on troyhunt.com
Tracking Scripts on troyhunt.com (Screenshot: Fabian A. Scherschel)

A good example is this blog post by the well respected security researcher and entrepreneur Troy Hunt (of Have I Been Pwned fame). The blog post argues that all websites should use TLS, even static sites like the The Private Citizen. In the post, Hunt is explaining why TLS is a good thing on static websites because it prevents people from man-in-the-middle attacks on the connection to those sites. All that is true and Hunt makes a good argument. His site is, of course, served over TLS. But at the same time, that very blog post has 11 tracking scripts embedded – from Google and Google-owned ad network DoubleClick to Twitter, Disqus and his own company Report URI. So why Hunt clearly has opinions on privacy, he doesn’t seem to care about it enough to proactively protect his readers. And that every possible connection to and from his site is encrypted doesn’t help the readers either.

I’m not condemning such scripts per se. I use some of them on my own site when I embed tweets or YouTube videos. I’m just trying to show that there are often more important privacy concerns than the question if the connection to the site in question is encrypted.

A detailed description of exactly what privacy guarantees there are when using TLS can be found in this very in-depth paper: The Privacy of the TLS 1.3 Protocol by Arfaoui et al.

The Private Citizen Website: A Case Study

Speaking of static sites, so why is The Private Citizen not served over TLS? While it would be pretty simple to enable HTTPS-only connections for the site itself – it’s a one-click setting at my hosting company – the server that delivers the podcast audio files I embed in these pages is another matter. It’s well within my capabilities to change that server over to HTTPS-only at some point and I’m planning to do that soon, but it is quite some work and I simply put higher priorities on earning a living and producing free content for all of you. Especially since there are bigger privacy concerns to be thought about with this site – like getting rid of any and all tracking scripts, for example.

And yes, I know about Let’s Encrypt. I’ve also had about two dozen people tell me how incredibly easy it is to set up. But the reality is that if you don’t use Apache and you have a non-standard configuration, it’s harder than these people think. Especially when the server you working on absolutely has to work and you need to do rigorous testing as part of the process. Additionally, I can’t just move the website now and the file server later because, thanks to the browser makers, mixed content like that is even more severely punished then just not doing TLS outright.

It’s also worth thinking about the actual use case here. This is a static website. Nobody is sending any information back to this server at all. So the only privacy gain you have from connecting via HTTPS is that other servers on your connecting route can’t see the content you’re pulling off this server. But all content on this website is open to the public anyway. So simply seeing which server you are connecting to is enough for people to know all of the content your are pulling off it – that is always the case, no matter if the connection is encrypted or not. And it’s not the job of TLS to protect against that anyway. Rather this hinges on the question if your DNS queries are encrypted and if you trust your DNS provider, which is a completely different question with a whole slew of other privacy implications.

If you don’t want people to know what content on the web you are consuming, you shouldn’t trust TLS. You should be using Tor.

To sum this up: I think TLS encryption is great and anybody who can implement it should implement it, no questions asked. I will do so for this site as soon as possible. But I also think we need to be aware of which problems TLS solves and which it doesn’t solve. And above all, we shouldn’t be blindly pressuring people into adopting it without trying to understand their particular situation.

The Browser Makers' Push for HTTPS Everywhere

Additionally, there are some things that make me weary of TLS. Especially the ill-conceived push to have all websites on the planet HTTPS encrypted that’s being undertaken by the makers of both major browsers on the market: Chrome and Firefox. I am weary, because those two browsers are backed by one of the biggest enemies of web privacy there is: Google. Chrome is developed directly by Google and Firefox, made by the self-proclaimed champions of web freedom at Mozilla, is to a large extent funded by Google.

So excuse me if I find it irritating when those browsers start to severely punish websites for not being served over TLS. Especially when those websites are then labelled as “unsecure”. Because, as we have seen, the security (or privacy) of the connection has nothing to do whatsoever with the security of the site itself. Let’s not even mention Google also punishing HTTP-only sites in their search results…

It’s hard to understate how much of a bigger threat Google and its business model is to the privacy of everyday users than a website not being available over TLS.

Let’s Encrypt has Cheapened TLS Certificates

I’m also uneasy about the continued infatuation by many technologically savy people with the Let’s Encrypt project. I just don’t see Let’s Encrypt as the shining beacon of hope that everyone makes it out to be. For me it’s more of an necessary evil. Let me try to explain what I mean by that.

While Let’s Encrypt has been instrumental in enabling everyone to essentially get free TLS certificates and has thus given a massive boost to TLS adoption across the web, it has also cheapened the meaning of these certificates.

When SSL/TLS was first created, the intent of the system was that certificate authorities would verify the identity of the organisation or person they issued a certificate to. The system was designed to not only give you confidence in your connection to a sever being securely encrypted, but also in the identity of whoever was operating that server.

While different certificate authorities have had a myriad of scandals and issues and while the verification process has been continuously cheapened throughout the existence of HTTPS, I really liked the concept. I also liked the idea behind extended validation certificates, even if the implementation of it was very flawed. Essentially, I liked the idea of improving the ID verification process, instead of making it more and more meaningless over time. Sadly, the existence of Let’s Encrypt has completely obliterated this idea.

With Let’s Encrypt, there are no checks at all. I literally push a button in the admin panel of my hosting company or fire off a script on my server. TLS certificates today do not guarantee anything about a server except the connection being encrypted securely and the fact that whoever provides the server is still the same entity. These automatically issued certificates do not give any guarantees about any other aspects of who is operating the server. Thus we now have malware authors and scammers routinely providing their websites over TLS connections.

One could argue that the CA system was flawed from the start and was moving in that direction anyway. But I simply liked the idea of pushing back and at least moving in the right direction instead of just completely giving up on it all.

Feedback

Stephen, a long time listener of my podcasts, reminded me of the correct pronounciation of “pseudo”.

be: /ˈs(j)uːdəʊ/ — ae: /ˈsuːdoʊ/

Thanks for that, Stephen. I’ll try to pronounce it correctly from now on.

In the Fediverse, Soul Dessin says:

Just listened to the new Private Citizen podcast. I liked it and the highlight of the surveillance program as well as how users are really affected.

All that I would love to have added is a small news section to spotlight the smaller but noteworthy pieces.

Also, as far as I can tell, about a thousand people have decided to tune into this podcast, which is pretty good for a show that’s just over two weeks old. I just wanted to mention this, because that is a kind of implicit feedback that I also look out for. I appreciate it!

If you also have thoughts on the things discussed here, please feel free to contact me.

Toss a Coin to Your Podcaster

I am a freelance journalist and writer, volunteering my free time because I love digging into stories and because I love podcasting. If you want to help keep The Private Citizen on the air, consider becoming one of my Patreon supporters.

This is entirely optional. This show operates under the value-for-value model, meaning I want you to give back only what you feel this show is worth to you. If that comes down to nothing, that’s OK with me, pard. But if you help out, it’s more likely that I’ll be able to keep doing this indefinitely.

Thanks and Credits

I like to credit everyone who’s helped with any aspect of this production and thus became a part of the show.

Aside from the people who have provided feedback and research and are credited as such above, I’m thankful to Raúl Cabezalí, who composed and recorded the show’s theme, a song called Acoustic Routes. I am also thankful to Bytemark, who are providing the hosting for this episode’s audio file.

But above all, I’d like to thank the following people, who have supported this episode through Patreon and thus keep this show on the air: Niall Donegan, Michael Mullan-Jensen, Jonathan M. Hethey, Georges Walther, Dave, Kai Siers, Matt Jelliman, Fadi Mansour, Joe Poser, Mark Holland, Steve Hoos, Butterbeans, Shelby Cruver, Dave Umrysh, RikyM and drivezero.