|
|
#X.509
|
|
|
|
|
|
X.509 certificates are the way TLS and other system transmit and store their private/public keys.
|
|
|
|
|
|
## What is wrong with X.509?
|
|
|
|
|
|
The format itself is a mess. The parser of the most used TLS implmentations (OpenSSL, libreSSL, gnuTLS) exceed the 20-30k lines of code. This is also due to the history of the format, where features have been introduced, then taken away, then reintroduced again.
|
|
|
|
|
|
In a very nice [article](http://blog.acolyer.org/2016/02/23/not-quite-so-broken-tls) on categorizing the latest TLS bugs, out of 54 bugs, 3 were in the certificate parsing and 5 in the validation of said certificates. That's not even that much, but the real problem is the revocation technology and the model that these certificates bring with themselves.
|
|
|
|
|
|
## What about the certificate authority model?
|
|
|
|
|
|
If we start using the X.509 certificate format we are implicitly using the certificate authority model.
|
|
|
|
|
|
This means that we are trusting a lot of different companies, some of which are in countries with oppressive
|
|
|
regimes, and others that have already issued certificates that they should have never issued.
|
|
|
|
|
|
Thanks to Let's encrypt, Startcom and CACert you could get free certificates, but only class2. class1 certificates, wildcards or even multi-domain certificates usually cost a lot. For something a lot of people don't even need.
|
|
|
|
|
|
|
|
|
## Certificate Revocation
|
|
|
|
|
|
Applications, and even operative systems should constantly update their list of certificate authorities.
|
|
|
This never happens, as cheap devices (like phones) rarely receive even one o.s. update in their life (think about cheap android phones). This is a big problem as a compromised authority, or one that we don't trust anymore, will remain present in thousand of devices.
|
|
|
|
|
|
### CRL -> OCSP
|
|
|
|
|
|
The same happens with _certificate revocation lists_. The X.509 model is thought to work offline, without constant checks with the certificate authority, as this was though not to scale. But how do we revoke a certificate then? We simply put a public list of the compromised certificates, and let the other keep that list updated. How? Your problem.
|
|
|
|
|
|
This is obviously a security nightmare. In fact, no one ever updates CRLs. at most a couple of times a year, which is definitely *not* enough, as ideally we would like instant deployment.
|
|
|
|
|
|
The solution to this problem was the OCSP protocol. In two words: check with the certificate authority servers if a certificate is still valid. Remember when we said "This won't scale"? Well, we obviously forgot about it.
|
|
|
|
|
|
OCSP also had a tiny little problem: If the server could not be contacted, the certificate was marked as valid. Which was pretty dumb, so they fixed it in later versions.
|
|
|
|
|
|
And since all of this doesn't scale, we are starting to put public keys in the DNSSEC system, for web and SMTP.
|
|
|
|
|
|
----
|
|
|
|
|
|
All of this means that we are already slowly evolving towards the solution implemented in Fenrir, so really, let's ditch the X.509 certificates and the certificate authority model.
|
|
|
|