Web PKI is Broken

A famous saying:

Web PKI revocation is broken.

But why is that? (and what does it mean?)

Let’s dive in. (2 min read)

To understand why we have a Web PKI revocation problem, we first need to understand why we have Web PKI...

PKI stands for Public Key Infrastructure - it is the infrastructure

To understand why we have a Web PKI problem, we first need to understand why we have Web PKI... and what it is.

PKI - Public Key Infrastructure

1) In the Web, we use HTTPS as the protocol of choice for communication. ??

2) In HTTPS we use certificates. Public keys are used for said certificates. But how do those work? ??

Certificates basically bind a public key and a DNS name (identity) together.

To give a website your personal information (credit card details), you need to trust it.

Certificates give you that baseline level of trust. They tell you that the website you’re connecting to is ACTUALLY the one you are expecting.

Through that key, you eventually use cryptography to encrypt the data between you and the server so that ONLY you and the server can read the data (nobody else) ??

HTTPS uses asymmetric cryptography to encrypt the data. You have one

?? private key - the website’s SSL certificate’s secret private key that isn’t shared with anyone.

?? public key - the certificate’s public key, shared with everyone who wants to interact with the website.

?? Asymmetric cryptography simply means information that’s encrypted by the public key can only be decrypted by the private key.

But how do you trust the certificate? ??

To trust a certificate, you must trust its Certificate Authority (CA).

CAs are basically third parties that distribute and manage certificates.

Side quest: how many CAs do you know and personally trust? :)

The trust typically comes from the Operating System and Browser you use. Those come pre-installed with trusted CAs.

The reason Web PKI is broken is simple - we don’t have a good answer on what to do when the certificate’s private key leaks.

What happens if an attacker gets a hold of that?

Bad things.

If the private key leaks, attackers can fool you into thinking they’re the original website. ??

Worse off?

If an intermediate certificate is compromised, the attacker could issue new, valid certificates for any domain, amplifying his reach. ??

For example, in 2011 there was a hack on DigiNotar which issued over 500 fake certificates on internet giants like Google, Microsoft and Twitter. They could have been used to send fake Windows updates to computers

So you definitely need a very good and fast way of INVALIDATING certificates.

But no good ways exist ??

Today, there are two main ways to revoke certificates:

- Certificate revocation list (CRL) - a signed blacklist of certificates that should NOT be used.

- Online certificate status protocol (OCSP) - it’s a protocol (over HTTP) used to communicate revoked certificates. “What if there were a separate CRL for every single certificate?”

But each have their problems:

CRLs Size

CRLs are basically just lists of all of the certificates that a given Certificate Authority (CA) has issued that have been revoked.

This means that they’re often very large – easily the size of a whole movie. And they only grow in size.

This then slows down the initial connection due to the required download.

OCSP Problems

Your browser can query the status for that particular certificate by contacting your CA's OCSP service.

But then we get to three problems:

- cache - to reduce the load on the services and the response time, we cache the response for ~a week. This means you can trust a revoked certificate for 7 days after it's been revoked. ??

- no privacy - with your certificate request, you're basically sharing your browser's history to the CA. (I want to visit this website) ??

- uptime - if the CA's service is down, you get no response. Browsers usually soft-fail in these cases and treat it as a "not revoked" response. (more on why later) That can’t be secure. ??

Perhaps due to these reasons, Google Chrome (63% market share) is the only browser that does NOT support OCSP since 2012, citing privacy and latency concerns, plus the fact that the soft-fail behavior invalidates all security in the cases it truly matters. ??

They implemented their own innovative mechanism (CRLSets).

Why Soft Fail

The uptime problem is not an easy one to solve.

A naive approach would be to have browsers hard-fail during CA downtime. (i.e if you can't get the certificate verification, treat it as expired)

That immediately gives you three large problems:

1. fragility - Changes incentives such that taking down an OCSP service is enough to take down a large part of the internet. DDoS attackers would turn to that honeypot, which would increase the costs of running a reliable OCSP service and make it so that CAs can’t afford it.

2. captive portals - things like hotel WiFi networks that want you to "login" before you can use the internet. They frequently use HTTPS but don't allow you to access OCSP servers.

3. random failures - even if the CA has 100% uptime, the public internet network is such that you may still get your request dropped for some reason. That means you'd have random cases where a website just doesn't load.

Unfortunately - there is no out-of-the-box way to do revocation.

It seems like there still isn’t an industry-wide consensus on the proper way to handle certificate revocation.

A 2015 research paper did 74 full IPv4 HTTPS scans and found that a surprisingly large fraction (8%) of the certificates served have been revoked.

They also studied the revocation-checking behavior of 30 different combinations of web browsers and operating systems, finding that browsers often do not bother to check whether certificates are revoked. At that time, mobile browsers never checked.

They also examined the CRLSet infra by Chrome and found it only covered 0.35% of all revocations.

The situation is better today, but this is still a problem that is NOT solved.

It’ll likely be a long time until revocation in the Web PKI is truly fixed.

What do you think?