Transport Layer Security (SSL/HTTPS)2016-09-18

Transport Layer Security (TLS) is the underlying technology behind secure and encrypted internet pages served over HTTPS.

Recently, there has been increasing pressure for the entire web to move to HTTPS. Browsers are starting to scare users on HTTP pages; Google is starting to give favor to HTTPS pages in their search results; and so on.

And although I have some concerns around the security of the underlying libraries that implement TLS (see OpenSSL and the Heartbleed vulnerability for just one example), I generally do agree that HTTPS is a positive for the web. What really opened my eyes to this was being the victim of a man-in-the-middle hijack from my very own ISP.

However, given the sorry state of the root certificate authority system today, this goal is going to remain unattainable, unless major changes are made.

Trust

The trusted root certificate authority (CA) system, as it works today, is fundamentally broken.

The way it works is, your browsers implicitly trust around a hundred root CAs. Any of these root CAs can then issue intermediate signing certificates. And unless they are explicitly barred through a special flag, they themselves can (and do) issue further intermediate signing certificates. There are thousands of these in existence. We don't even have a way to enumerate all of them. And yet your browser trusts every single one.

Any of these can sign certificates for any domain on the internet. What stops them? Auditing, basically. But this is far from foolproof, as we've seen with both Diginotar and CNNIC's intermediate MCS Holdings caught signing rogue google.com certificates.

Further, these CAs exist in virtually every country in the world. All it takes is one hostile government to demand that a CA issue them fradulent certificates, and require them to keep it a secret.

We have a lot of band-aids put in place to try and protect against this, such as public-key pinning (HPKP), certificate revocation lists (CRLs) and certificate transparency (CT) ... but all of these are opt-in. And they do not solve the problem of the very first connection to a new server.

Further, browsers intentionally undermine your trust by allowing locally installed certificates to masquerade as any domain they like. This is used by employers, schools, etc to snoop on their users' encrypted traffic. Rogue software can also install these certificates without your knowledge. Now certainly, the argument can be made that someone who can install certificates onto your local machine already has control over it ... but that doesn't mean we should give them a golden backdoor to do it, and lie to users by telling them their connections are encrypted and secure, when they very much are not.

But what's so tragic about this, is how unnecessary it all is. We have several alternatives that could provide much stronger protections.

One example is to use DNSSEC (signed DNS) with DANE to validate that the certificate being served by a domain is the real certificate. And this check can be done without requiring an initial secure connection as with HPKP.

Another would be a peer-based model where certificates are cross-validated by the browser through various services that also fetch and cache domain endpoint certificates. This would effectively make rogue CA man-in-the-middle attacks impossible.

Unfortunately, better alternatives have been completely eschewed by the browser vendors, and the reason for that is simple ...

Cost

Money. SSL certificates are big business. CAs pull in billions of dollars a year. This is how Mark Shuttleworth of Ubuntu fame earned his millions, when he sold his CA company Thawte to Symantec for $575 million in 1999. Yes, 1999! Given the exponential growth of the internet, imagine how much the CA business is worth in 2016!

Technologies such as DANE and peer-based authentication would allow the millions of website operators out there to safely and securely self-sign their own certificates. So don't be surprised that none of the multi-million dollar a year in revenue browser vendors are going to do anything that might harm that business.

So if you want a certificate that covers your entire domain, you're looking at potentially hundreds of dollars a year to buy one from companies such as Verisign, Comodo, Symantec, etc.

However, security should not cost money! Especially not if you want it to become ubiquitous.

I understand paying for human validation services through extended validation (EV) certificates for businesses looking to take your credit card information (even though most sites that do so do not use EV certificates); but for a personal website that simply wants to protect its users from eavesdropping and man-in-the-middle attacks, there should be no charge for automated certificates.

Others apparently agree, and there exists a mere two CAs that will issue you free certificates that are recognized by modern browsers. Yet unfortunately, both impose extreme limitations that do not apply to those who pay for security.

StartSSL Free

StartSSL will provide you with a free certificate valid for one year, but only for your root domain.

This is an instant non-starter to sites that use subdomains, which is incredibly common. byuu.org has board, files, download, doc, etc subdomains. And if you want to use separate physical servers (say, a separate mail server), then you have no choice but to use subdomain DNS A records for this purpose.

Further, should your certificate's private key become compromised (as was the case with Heartbleed), StartSSL will charge you a fee to revoke your "free" certificates.

Let's Encrypt

Let's Encrypt will offer to secure multiple subdomains for you, but only those that you can name in advance. They further impose a limit of five certificates per week containing up to one hundred subdomains per certificate.

While this is certainly enough for most domains, it does require the added difficulty of having to request these every time you add a new subdomain to your site.

Further, it completely rules out a very important use case: take the model of sites like Blogspot and DeviantArt — they allow their users to register their own subdomains. This model would be all but impossible under Let's Encrypt.

This is an entirely artificial limitation that is easily remedied by issuing what is known as a wildcard certificate. However, Let's Encrypt has steadfastly refused to offer these to its users.

As a second hurdle, Let's Encrypt only offers certificates with a validity of a mere ninety days!! If your certificate were to expire, it would lock all of your users out of the HTTPS version of your website. And if you were doing things the way you are encouraged to by redirecting HTTP traffic to HTTPS and using HSTS headers, then your website would become completely unusable until you were able to update your certificate.

Their solution to both of these limitations is asking you to install their certbot software onto your server.

By default, this software requires root access. Ostensibly so that it can update your HTTP server software's configuration files for you, and to reach out to grab updated certificates for you automatically.

This is completely unacceptable to many companies, as well as many personal users such as myself: it is my goal to minimize third-party software running on my server. Especially any software that requires root access.

Now yes, the software is open source. But who can really audit software to ensure it is entirely safe and free of any backdoors? If you think you can, then I encourage you to check out the IOCCC's underhanded coding competition.

And yes, you can technically modify the software to run as a regular user. But now you've lost the automation portion since it can no longer modify your server configuration and restart your HTTP servers. Which is a really major deal with certificates that expire every 90 days. That's a lot of added work.

And finally yes, there are third-party versions of certbot should you want to peruse other possible implementations. But they suffer from the exact same problems as certbot itself does. And now they come from potentially even less trusted sources.

This is another odious limitation: any of the paid CAs will happily sell you a certificate that lasts for multiple years, and you can request it right from a webpage form: no software installation required.

Hypocrisy

Reading their official reasons for these limitations ... Let's Encrypt states that most users do not need wildcard certificates, and as such, they have no plans to offer them to their users.

Nevermind that this is just an excuse, rather than an explanation of why they won't offer them ... if you look at eff.org, you will see that it utilizes wildcard certificates! So apparently it's okay for the owners of Let's Encrypt to use wildcard certificates, but not okay for any of their users to use them.

So what about the 90-day limitation on certificate length? Let's Encrypt states that this is a security feature to ensure shorter certificate lengths for when certificates are compromised.

But is it really? Is 90-days with a vulnerable certificate acceptable? Of course not. This is why we have certificate revocation lists, to handle this exact scenario.

And if you look at the certificate for letsencrypt.org, you will find that theirs is valid for a full three years!! That is twelve times longer than the longest certificate they will give to you. Do they believe themselves to be better at web server security than any of their users?

They've been called out on this before. Their official response is that they registered the certificate before the service went live, and before they decided on the 90-day policy for their users.

... but their service has been live since April 2016. Surely if this is such an important security concern, they could have registered a new certificate by now?

Do as we say, not as we do

So they use wildcards, and they use three-year long certificates. Yet they are forbidding their users from enjoying the very same benefits they themselves enjoy! But if you are going to preach and impose these limitations, then surely you should eat your own dogfood, right? Lead by example!!

But of course, they don't. And why not? Because these things are immensely useful, of course! Wildcard certificates enable many use cases that are just impossible otherwise; and longer expiration dates make using public-key pinning much safer. It's no surprise at all that they would value and use these features. It's just a shame they won't in turn offer these same features to their users.

Summary

So to recap, Let's Encrypt imposes the following restrictions that do not exist with paid certificate authorities:

As such, Let's Encrypt is not a truly free alternative to paid CAs. It is a crippled service with severe limitations.

Its defenders will tell you that if you need to protect your entire domain, or need longer certificate lifetimes, or cannot (by company policy) or will not (by lack of trust) run third-party software to generate your certificates ... that Let's Encrypt is not the service for you.

... and frankly, I couldn't agree more.

I truly don't want to rag on an entirely free service like Let's Encrypt here. But the real problem is, we've already established that StartSSL Free is a complete non-starter. And Let's Encrypt is the only other alternative without paying money. So this is a real problem.

Civil disobedience

Being an ardent believer that security should not cost money, I tried to resist this by using a self-signed certificate, combined with distribution of the certificate over secure channels.

However, the browser vendors have made this all but impossible.

They use scare tactic dialog messages that make browsing a site over unencrypted HTTP perfectly safe; yet they make it dozens of times easier to run native executable code downloaded from the internet on your machines than to simply view a website with a self-signed certificate.

Even then, if you can find the hidden options and go through multiple dialogs to confirm that you trust the certificate, it will refuse to recognize the certificate on any other subdomains, forcing users to have to constantly confirm each and every subdomain you use.

And trying to walk your users through installing a signing certificate is pretty much guaranteed to be a non-starter.

Further, you aren't even given the opportunity to redirect users to an HTTP page explaining the use of self-signing certificates. The moment a user goes to your HTTPS page, they are immediately blocked from viewing your site at all.

As stated earlier, all possible (and more secure) alternatives that would allow for self-signed certificates have been roundly rejected: DNSSEC+DANE, peer-based validation, etc.

And even if you fight through all of this and use a self-signed certificate anyway, you're still forced to make several substantial concessions:

Throwing in the towel

And so, for all of the above reasons, I gave in. For a 'small' three-figure sum, I purchased a certificate from a CA that gives me the same features letsencrypt.org and eff.org enjoy. The only validation done was asking me to put a <meta> tag on my website momentarily. Security my ass, the only thing this process has proven is that I have a lot of money to throw away.

But I am not happy about it. This is money that could have gone to much more important things. My website, which gives away entirely free software, does not have any ads, does not sell anything, and does not earn any revenue whatsoever, was forced to pay more for a certificate than I pay for domain registration, domain privacy protection, DNS hosting, and server hosting combined!!

And while I can afford to do so, we need to recognize that there are many people out there who cannot. And that's not just making them less safe: it's making all of us less safe.

This situation cannot stand on what is supposedly a free and open internet.