Chapter 9iv: Certificate Revocation Flashcards
Certificate Revocation
Revocation is crucial—yet often neglected in discussions
Problems?
* There are several cases when an already issued certificate must be withdrawn. Examples?
Solutions?
Certificate Revocation Lists (CRLs)
A CRL is a list of certificates that are considered revoked. Explain.
- They are (should be) issued, updated and maintained by every CA:
- Certificates are identified by serial number
- A reason for revocation can be given
- Every CRL must be timestamped and signed
- There are further entries, like time of next update
- Technically, a browser (client) should download CRL (and update it after the given time), and lookup a host certificate every time it connects to a server
Problems with CRLs
Explain.
- For these reasons, browsers have never activated CRLs by default
- Intermediate certs should be checked, too – induces load and network activity
- There is a time interval between two updates (window for attack)
- CRLs can grow large
- Response to this: Delta CRLs that contain only latest updates
- Requires server side support—very rarely used
- Downloads of CRLs can be blocked by a Man-in-the-middle
Online Certificate Status Protocol (OCSP)
OCSP allows live revocation checks over the network. Query-Response model.
Problems with OCSP
Online Certificate Status Protocol (OCSP): OCSP Stapling
Addresses several problems of OCSP
- The idea is thus that servers request fresh OCSP ‘proof’ from CA: ‘this certificate is still considered valid’
- This can be done at regular intervals
- The ‘proof’ is ‘stapled’ to the certificate that the server sends in the SSL/TLS handshake
- Although around for a long time, the idea is only now gaining traction
- Reduces load on CA, reduces overall web page loading time, solves privacy problem
New Approaches to Revocation
Revocation: Lessons Learned
Revocation is crucial—but no silver bullet so far
* It is probably safe to say that …
* OCSP checks are expensive, too (latency, load)—and …
* OCSP stapling is an improvement
* Revocation is an unsolved problem
CRLs never worked and are of very limited use
not sufficient against an attacker who drops traffic
to the CA
Proposals to enhance X.509 DigiNotar vs. Iran?
- CA can issue certificates for any Web server
- If a CA is rogue or got compromized, malicious certificates can be issued
- This certificate enables an attacker to act as Man in the Middle (“TLS/SSL proxy”)!
Certificate Pinning
Aim: defend against malicious certs
- Idea: browser “pins” the certificate a Web server presented on first contact
- Can be achieved by storing the public key or hash of the public key
- If the server later presents a different certificate, the browser can warn the user or stop the connection attempt
Certificate Pinning
This type of user-driven pinning assumes a secure first connection
- Inherent bootstrapping problem: who can guarantee the cert’s authentifity on first use?
- Browser might pin the malicious certificate…!
- Thus also known as trust-on-first-use (“TOFU”)
Certificate Pinning: Further Pinning Variants
Static vs Dynamic pinning
Certificate Pinning Issues to solve
TOFU, Lifecycle, Scalability
- Today, pinning is mostly replaced by Certificate Transparency (CT)
- CT are public logs of certificates issued by CA
- Browsers (and other entities) can query the logs to find malicious certificates
