Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
F
Fenrir_Project
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Fenrir
  • Fenrir_Project
  • Wiki
  • X.509

X.509

Last edited by Luker Apr 01, 2016
Page history

#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 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.


Clone repository
  • Auth_Details
  • CLA
  • Comparison
  • Current_Auth_Schemes
  • DNSSEC_Details
  • Development
  • Federated_vs_Distributed
  • Federation_Details
  • Luca_Fulchir
  • Multicast
  • OAuth_Hate
  • Packet_Structure
  • Paper
  • Proxy
  • QUIC
More Pages