6 ms·

Revocation of X.509 Certificates

52 points by jandeboevrie 6mo ago

lmm 6mo ago
[flagged]
- _bernd 6mo ago
  The author has a long history of quality content and should be considered experienced in his field of doing.
- jcgl 6mo ago
  Agreeing with my sibling commenter, this writer is extremely experienced and has been writing this blog for many years. I’d be appalled if this were LLM-written, but thankfully it reads with the same style and tone that he’s always had. > Revocation is an emergency measure, not a routine one. That's ok. At the scale modern CAs operate, even emergency measures (i.e. measures that are an emergency for the party receiving the leaf cert) are also routine for the CA/the party granting the leaf cert.
- PunchyHamster 6mo ago
  > Because DNS' multilayered caching makes it notoriously impossible to operate safely or debug. That is not a problem for certs, you are not changing it every second. And the "impossible to operate or debug" is just plain failse or incompetence > Most large outages already originate in DNS issues; putting the crypto in that layer would redouble it. That is also just not true. Also, outage of DNS coz someone fucked up configuration management somewhere is not caused by anything related to DNS, it just so happens DNS is essential so any problem is visible.
  - lmm 6mo ago
    > That is not a problem for certs, you are not changing it every second. The problem is when you screw it up and can't fix it for 24 hours or worse.
    - PunchyHamster 6mo ago
      Well then don't set validity for 24 hours.
      - lmm 6mo ago
        Most technologies work great when you simply don't make mistakes.
- miyuru 6mo ago
  looks like so, the emojies are dead give away. I am not against using LLMs, but the author should have validated the contents before posting.
  - aragilar 6mo ago
    If you look at the older article linked (https://www.potaroo.net/ispcol/2022-03/revocation.html https://www.potaroo.net/ispcol/2022-03/revocation.html), it's very similar and uses the same tick/cross, so I don't think it's AI generated.
- aragilar 6mo ago
  In addition to what other commenters have said, it's a copy of a post on their personal blog: https://www.potaroo.net/ispcol/2026-04/revocation.html https://www.potaroo.net/ispcol/2026-04/revocation.html On revocation, check out https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Progra... I don't think any CA hasn't had an issue with revocation at some point (e.g. Let's Encrypt had a major one in 2021, and refused to revoke), which is why Let's Encrypt is moving to 7 day certs (so that revocation isn't required, basically https://www.imperialviolet.org/2011/03/18/revocation.html https://www.imperialviolet.org/2011/03/18/revocation.html which is mentioned in the article). My impression is CRLs (and by implication current revocation methods) don't work, and browsers are effectively fudging around CAs with custom methods (e.g. allowing existing certs but no new certs from distrusted CAs). I'm no security expert, but modern bind9 seems to just handle DNSSEC with no issues when I've used it, and given that the "WebPKI" seems is becoming more and more reliant on custom browser code, adopting DANE outside browsers might not be the worst idea.
  - lmm 6mo ago
    > I don't think any CA hasn't had an issue with revocation at some point (e.g. Let's Encrypt had a major one in 2021, and refused to revoke) Every software org has had issues with every piece of functionality, revocation isn't special. > modern bind9 seems to just handle DNSSEC with no issues when I've used it The happy path works. Everything is fine until it isn't. Very few people are confident enough to fully deploy it.
    - aragilar 6mo ago
      According to https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec DNSSEC is sitting about 1/3, so "very few" isn't accurate. I'm not suggesting browsers should change what they do, but if WebPKI can't be used, building a new CA ecosystem would seem to be to be at least as hard as getting DANE working.
- crote 6mo ago
  > Revocation is an emergency measure, not a routine one. That's ok. Rather the opposite: revocation is the one time it actually matters, so your infrastructure shouldn't come to a grinding halt when it happens! Let's say a party like LetsEncrypt needs to do a mass revocation of all certificates. Unlikely, but it has happened before. This is going to instantly blow up the CRL from perhaps a few thousand to 700 million entries. Force every browser to download that regularly and you've essentially accidentally created a DDoS on LetsEncrypt's CRL service. And how do you want the browser to respond? Fail-closed and you've just created a method to take 80% of the internet offline by DDoSing a single service, fail-open and you've just created a method for an attacker to bypass certificate revocation entirely. With critical infrastructure like this you can't get away with only thinking about the happy path. It should always work - even in emergencies.
  - fc417fc802 6mo ago
    > fail-open and you've just created a method for an attacker to bypass certificate revocation entirely I generally agree about the rest but isn't what you suggest there sufficiently disproportionate to fall well outside the threat model? It buys only a limited window of opportunity in a very specific scenario while painting a neon target on your back. I feel like it's vaguely akin to worrying about a military checkpoint failing open when hit with a 30k lb bomb.
thayne 6mo ago
> At this point, why not just use DANE Interests of the existing PKI industry may be the source of some friction, but the bigger issue is that DANE depends on DNSSEC, which is not widely deployed, and sometimes actively avoided due to its complexity and ease of breaking you site. Don't get me wrong, I'd love it if DANE, or something similar caught on, but I don't think it is practical until something changes to make DNSSEC (or equivalent) common.
- PunchyHamster 6mo ago
  > Interests of the existing PKI industry may be the source of some friction, but the bigger issue is that DANE depends on DNSSEC, which is not widely deployed, and sometimes actively avoided due to its complexity and ease of breaking you site. I have a feeling it is "actively avoided" because vendors don't want to lose control of the cert ecosystem. Allowing user to just generate a domain for themselves means it will never get logged in central log and so can't be automatically found by crawlers by the big guys
  - xorcist 6mo ago
    This is public data so the big guys could absoltely crawl it. But we should not underestimate the size of the PKI industry, several large actors make good living from the existing web PKI and they will not change unless their very existence is threatened.
  - Parodper 6mo ago
    > Allowing user to just generate a domain for themselves That's limited mostly by policy[1], the current PKI environment already allows delegating CA for a single domain. [1] https://community.letsencrypt.org/t/sub-ca-with-wildcard-certificate/237578/8 https://community.letsencrypt.org/t/sub-ca-with-wildcard-cer...
    - PunchyHamster 6mo ago
      Last time I checked support for that on client side was pretty spotty
bblb 6mo ago
DNS and PKI. Two of the most centralized services in the Internet. Take over both of them, and you have the whole net under your command.
- pjf 6mo ago
  Good that at least BGP is secure.
  - nanis 6mo ago
    Might want to add /sarc just in case someone believes it :-)
- jumpconc 6mo ago
  Just DNS. If you take over DNS, you can get Let's Encrypt to issue any certificate you want.
  - pjf 6mo ago
    There are situations [1] where you could reliably BGP-hijack the IP prefix of the target domain authoritative nameserver, and obtain your own domain-validated cert for the target (by effectively controlling the zone file contents). And yeah, CAs do have their BGP protections, but still there's at least partial assumption BGP is secure enough to run DNS-based validation for new SSL certs, in our world where DNSSEC is still rare. [1] https://www.ietf.org/proceedings/104/slides/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-00.pdf (see slide 15; yeah, it's already a bit old, yet still the case from my practice)
crote 6mo ago
> With this approach, they have shown a reduction in CRL data from a list of all enrolled and unexpired certificate serial numbers from 6.7G to a filter of just 1.3 MB. It actually gets even better: Mozilla's CRLite deltas with generation on a 6-hour interval are only about 60kB! Even with 10 billion internet devices fetching every 6 hours you're looking at a mere 222Gbps of bandwidth: a lot, but plenty of tech companies do more. > At this point, why not just use DANE (RFC 6698), store the public keys in the DNS, rely on DNSSEC to provide the necessary authenticity, and use DNS TTL settings to control the cached lifetime of the public key? With a combination of DNSSEC Chain Extensions and DNSSEC stapling, it is possible to perform a security association handshake by having the server provide the client with (...) Yeah, until an attacker gets access to DNS, stores a record with a TTL of 1 year, and staples that - of course after poisoning the caches of major DNS resolvers with the address of the attacker's server.
- pjf 6mo ago
  On the other front (Chrome), their crlset-tools [1] just fetched me 64k (~1.1MiB) of revoked certs just fine, contrary to the article (quote: "After retrieving and running this tool, I was surprised to see a total of 1,081 revoked certificate serial numbers in this list. This seems oddly low.") [1] https://github.com/agl/crlset-tools https://github.com/agl/crlset-tools
- xorcist 6mo ago
  > until an attacker gets access to DNS, stores a record with a TTL of 1 year, DNSSEC may have problems, but that's not how the trust model works. Also signing is separate from authoritative DNS, so you'd need to compromise the signing itself, not just DNS. Should that happen, you are still limited by the upstream record siganture lifetime.
Parodper 6mo ago
It's funny to see that the issues with X.509 certificates, are being solved by what X.509 was intended to be used for: a directory system. It's DNS instead of X.500, but it's a start.
PeterWhittaker 6mo ago
One quibble with the article: the notion that CRLs have to be large. When I was with Entrust our first releases targeted early Windows versions with limited memory, back when most Internet connections and even local networks were slow. To ensure that RLs would always be manageable in size, we used distribution points (cRL and issuing) and decided at certificate issuance which RL would contain this certificate's serial number if ever it were revoked. This approach scaled really well and kept RLs manageable. There were applications that didn’t understand distribution points and needed the One RL to Revoke Them All, so we supported that as well (as an option, IIRC).

52 points by jandeboevrie 6mo ago

lmm 6mo ago

[flagged]

_bernd 6mo ago
The author has a long history of quality content and should be considered experienced in his field of doing.
jcgl 6mo ago
Agreeing with my sibling commenter, this writer is extremely experienced and has been writing this blog for many years. I’d be appalled if this were LLM-written, but thankfully it reads with the same style and tone that he’s always had. > Revocation is an emergency measure, not a routine one. That's ok. At the scale modern CAs operate, even emergency measures (i.e. measures that are an emergency for the party receiving the leaf cert) are also routine for the CA/the party granting the leaf cert.
PunchyHamster 6mo ago
> Because DNS' multilayered caching makes it notoriously impossible to operate safely or debug. That is not a problem for certs, you are not changing it every second. And the "impossible to operate or debug" is just plain failse or incompetence > Most large outages already originate in DNS issues; putting the crypto in that layer would redouble it. That is also just not true. Also, outage of DNS coz someone fucked up configuration management somewhere is not caused by anything related to DNS, it just so happens DNS is essential so any problem is visible.
- lmm 6mo ago
  > That is not a problem for certs, you are not changing it every second. The problem is when you screw it up and can't fix it for 24 hours or worse.
  - PunchyHamster 6mo ago
    Well then don't set validity for 24 hours.
    - lmm 6mo ago
      Most technologies work great when you simply don't make mistakes.
miyuru 6mo ago
looks like so, the emojies are dead give away. I am not against using LLMs, but the author should have validated the contents before posting.
- aragilar 6mo ago
  If you look at the older article linked (https://www.potaroo.net/ispcol/2022-03/revocation.html https://www.potaroo.net/ispcol/2022-03/revocation.html), it's very similar and uses the same tick/cross, so I don't think it's AI generated.
aragilar 6mo ago
In addition to what other commenters have said, it's a copy of a post on their personal blog: https://www.potaroo.net/ispcol/2026-04/revocation.html https://www.potaroo.net/ispcol/2026-04/revocation.html On revocation, check out https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Progra... I don't think any CA hasn't had an issue with revocation at some point (e.g. Let's Encrypt had a major one in 2021, and refused to revoke), which is why Let's Encrypt is moving to 7 day certs (so that revocation isn't required, basically https://www.imperialviolet.org/2011/03/18/revocation.html https://www.imperialviolet.org/2011/03/18/revocation.html which is mentioned in the article). My impression is CRLs (and by implication current revocation methods) don't work, and browsers are effectively fudging around CAs with custom methods (e.g. allowing existing certs but no new certs from distrusted CAs). I'm no security expert, but modern bind9 seems to just handle DNSSEC with no issues when I've used it, and given that the "WebPKI" seems is becoming more and more reliant on custom browser code, adopting DANE outside browsers might not be the worst idea.
- lmm 6mo ago
  > I don't think any CA hasn't had an issue with revocation at some point (e.g. Let's Encrypt had a major one in 2021, and refused to revoke) Every software org has had issues with every piece of functionality, revocation isn't special. > modern bind9 seems to just handle DNSSEC with no issues when I've used it The happy path works. Everything is fine until it isn't. Very few people are confident enough to fully deploy it.
  - aragilar 6mo ago
    According to https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec DNSSEC is sitting about 1/3, so "very few" isn't accurate. I'm not suggesting browsers should change what they do, but if WebPKI can't be used, building a new CA ecosystem would seem to be to be at least as hard as getting DANE working.
crote 6mo ago
> Revocation is an emergency measure, not a routine one. That's ok. Rather the opposite: revocation is the one time it actually matters, so your infrastructure shouldn't come to a grinding halt when it happens! Let's say a party like LetsEncrypt needs to do a mass revocation of all certificates. Unlikely, but it has happened before. This is going to instantly blow up the CRL from perhaps a few thousand to 700 million entries. Force every browser to download that regularly and you've essentially accidentally created a DDoS on LetsEncrypt's CRL service. And how do you want the browser to respond? Fail-closed and you've just created a method to take 80% of the internet offline by DDoSing a single service, fail-open and you've just created a method for an attacker to bypass certificate revocation entirely. With critical infrastructure like this you can't get away with only thinking about the happy path. It should always work - even in emergencies.
- fc417fc802 6mo ago
  > fail-open and you've just created a method for an attacker to bypass certificate revocation entirely I generally agree about the rest but isn't what you suggest there sufficiently disproportionate to fall well outside the threat model? It buys only a limited window of opportunity in a very specific scenario while painting a neon target on your back. I feel like it's vaguely akin to worrying about a military checkpoint failing open when hit with a 30k lb bomb.

thayne 6mo ago

> At this point, why not just use DANE Interests of the existing PKI industry may be the source of some friction, but the bigger issue is that DANE depends on DNSSEC, which is not widely deployed, and sometimes actively avoided due to its complexity and ease of breaking you site. Don't get me wrong, I'd love it if DANE, or something similar caught on, but I don't think it is practical until something changes to make DNSSEC (or equivalent) common.

PunchyHamster 6mo ago
> Interests of the existing PKI industry may be the source of some friction, but the bigger issue is that DANE depends on DNSSEC, which is not widely deployed, and sometimes actively avoided due to its complexity and ease of breaking you site. I have a feeling it is "actively avoided" because vendors don't want to lose control of the cert ecosystem. Allowing user to just generate a domain for themselves means it will never get logged in central log and so can't be automatically found by crawlers by the big guys
- xorcist 6mo ago
  This is public data so the big guys could absoltely crawl it. But we should not underestimate the size of the PKI industry, several large actors make good living from the existing web PKI and they will not change unless their very existence is threatened.
- Parodper 6mo ago
  > Allowing user to just generate a domain for themselves That's limited mostly by policy[1], the current PKI environment already allows delegating CA for a single domain. [1] https://community.letsencrypt.org/t/sub-ca-with-wildcard-certificate/237578/8 https://community.letsencrypt.org/t/sub-ca-with-wildcard-cer...
  - PunchyHamster 6mo ago
    Last time I checked support for that on client side was pretty spotty

bblb 6mo ago

DNS and PKI. Two of the most centralized services in the Internet. Take over both of them, and you have the whole net under your command.

pjf 6mo ago
Good that at least BGP is secure.
- nanis 6mo ago
  Might want to add /sarc just in case someone believes it :-)
jumpconc 6mo ago
Just DNS. If you take over DNS, you can get Let's Encrypt to issue any certificate you want.
- pjf 6mo ago
  There are situations [1] where you could reliably BGP-hijack the IP prefix of the target domain authoritative nameserver, and obtain your own domain-validated cert for the target (by effectively controlling the zone file contents). And yeah, CAs do have their BGP protections, but still there's at least partial assumption BGP is secure enough to run DNS-based validation for new SSL certs, in our world where DNSSEC is still rare. [1] https://www.ietf.org/proceedings/104/slides/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-00.pdf (see slide 15; yeah, it's already a bit old, yet still the case from my practice)

crote 6mo ago

> With this approach, they have shown a reduction in CRL data from a list of all enrolled and unexpired certificate serial numbers from 6.7G to a filter of just 1.3 MB. It actually gets even better: Mozilla's CRLite deltas with generation on a 6-hour interval are only about 60kB! Even with 10 billion internet devices fetching every 6 hours you're looking at a mere 222Gbps of bandwidth: a lot, but plenty of tech companies do more. > At this point, why not just use DANE (RFC 6698), store the public keys in the DNS, rely on DNSSEC to provide the necessary authenticity, and use DNS TTL settings to control the cached lifetime of the public key? With a combination of DNSSEC Chain Extensions and DNSSEC stapling, it is possible to perform a security association handshake by having the server provide the client with (...) Yeah, until an attacker gets access to DNS, stores a record with a TTL of 1 year, and staples that - of course after poisoning the caches of major DNS resolvers with the address of the attacker's server.

pjf 6mo ago
On the other front (Chrome), their crlset-tools [1] just fetched me 64k (~1.1MiB) of revoked certs just fine, contrary to the article (quote: "After retrieving and running this tool, I was surprised to see a total of 1,081 revoked certificate serial numbers in this list. This seems oddly low.") [1] https://github.com/agl/crlset-tools https://github.com/agl/crlset-tools
xorcist 6mo ago
> until an attacker gets access to DNS, stores a record with a TTL of 1 year, DNSSEC may have problems, but that's not how the trust model works. Also signing is separate from authoritative DNS, so you'd need to compromise the signing itself, not just DNS. Should that happen, you are still limited by the upstream record siganture lifetime.

Parodper 6mo ago

It's funny to see that the issues with X.509 certificates, are being solved by what X.509 was intended to be used for: a directory system. It's DNS instead of X.500, but it's a start.

PeterWhittaker 6mo ago

One quibble with the article: the notion that CRLs have to be large. When I was with Entrust our first releases targeted early Windows versions with limited memory, back when most Internet connections and even local networks were slow. To ensure that RLs would always be manageable in size, we used distribution points (cRL and issuing) and decided at certificate issuance which RL would contain this certificate's serial number if ever it were revoked. This approach scaled really well and kept RLs manageable. There were applications that didn’t understand distribution points and needed the One RL to Revoke Them All, so we supported that as well (as an option, IIRC).