3 ms·

Then shouldn't revocation be fixed?

AnthonyMouse 12y ago
Revocation is Hard. The problem is that the way certificates work is supposed to be asynchronous: You get a certificate from the CA, the client has the CA's public key, so you give the certificate to the client which can verify it without talking to the CA. This is pretty important if you want to secure something that needs to keep working even if it isn't on the internet, or the internet is down, or the CA's servers are down (or under DoS), etc. But you can't do revocation that way. The client can get the certificate from the server being certified, but it can't get a revocation that way because nothing forces the server provide the revocation. To do revocation you have to have a database of all the revoked certificates and check every certificate against the database before accepting it. But there are too many revoked certificates to store on the client; the database is too big. And if the client has to query some server then the attacker can DoS or MITM that server. The best way to handle "revocation" is to fully automate certificate issuance like Let's Encrypt, but then only issue certificates for a short period of time, like 10 days (but renewed every 7). Then you don't have to worry about revocation because the certificate expires in about the same amount of time it would take to be detected and distributed in a revocation database.
- fpgaminer 12y ago
  Seems like a bloom filter may work to deal with the large database of revoked certificates.
  - AnthonyMouse 12y ago
    Bloom filters have false positives. Then you need some way to verify that a hit isn't a false positive, and whatever method is used for that will have the same availability problem in verifying a hit in the bloom filter as it would have in obtaining the revocation that way to begin with.
- PeterWhittaker 12y ago
  There is another solution, the CRL Distribution Point, or CDP. Entrust implemented this rather elegantly in their product starting in the mid 1990s and still use it today. Instead of having a monolithic CRL, the CA publishes smaller CRLs and writes the CRL location on which a certificate would appear if revoked in the certificate itself. In other words, every X certificates, the CA creates a new CDP, call it CDP_n, and all subsequent certificates issued between now and +X from now have the location of CDP_n written in them: That's where you look for their CRL. +X certificates from now, the CA creates CDP_n+1 and starts writing that into the certs. The size of X can be set, tuned, based on certificate lifetimes, number of users, etc., etc. If you want your CRLs to be fresher, use a smaller X, have more CDPs. The other nice thing about the CDP is that it ties the CRL retrieved from wherever (an LDAP repo, a web site, etc.) to the certificate: The certificate contains within its signed payload a reference to the CDP location and the CRL contains within its signed payload a reference to the same location (the issuingDistributionPoint) so you have a high integrity check that the CRL being used to verify the certificate is actually the right one, even if the certificate is valid and therefore not listed thereupon. This prevents an attacker from fooling you into trusting a revoked certificate by replacing its CRL with one that doesn't match it: The replacement CRL will have the wrong iDP, one that does not correspond to the CDP in the cert.
- wiml 12y ago
  > only issue certificates for a short period of time, like 10 days (but renewed every 7) That's essentially the situation we're in with OCSP stapling, if you consider the certificate plus OCSP response to be the certificate. (The "must staple" cert extension[1] would make it even more similar.) [1] https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeatur...
  - AnthonyMouse 12y ago
    Someone please tell me why doing it that way is better than the following: You validate yourself in the usual way and present a CSR to the CA. The CA signs the certificate but only with a very short expiration. However, unless the certificate is "revoked", you can come back at any point and the CA will automatically sign an identical certificate with the sole exception of the expiration date. (Then maybe they stop after e.g. two years unless you validate again, to keep an "actual" expiration.) The advantage of that over OCSP stapling is that it requires zero modification to the client. What advantage does OCSP stapling have over that?
- itistoday2 12y ago
  > The best way to handle "revocation" is to fully automate certificate issuance like Let's Encrypt, but then only issue certificates for a short period of time, like 10 days (but renewed every 7). Then you don't have to worry about revocation because the certificate expires in about the same amount of time it would take to be detected and distributed in a revocation database. That can make it less likely that your certs will be used in revocation attacks. It does absolutely nothing to protect your visitors from other compromised certificates. The "best" known way (to my knowledge) is to use a blockchain, which doesn't have the revocation problem. Here is a comparison of a blockchain-based approach I'm working on with some other folks called DNSChain to other approaches people have suggested: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
wolf550e 12y ago
Read Adam Langley's blog about revocation. Only 19.9% of secure sites currently support OCSP stapling [1]. 1 - https://www.trustworthyinternet.org/ssl-pulse/ https://www.trustworthyinternet.org/ssl-pulse/

Revocation is Hard. The problem is that the way certificates work is supposed to be asynchronous: You get a certificate from the CA, the client has the CA's public key, so you give the certificate to the client which can verify it without talking to the CA. This is pretty important if you want to secure something that needs to keep working even if it isn't on the internet, or the internet is down, or the CA's servers are down (or under DoS), etc. But you can't do revocation that way. The client can get the certificate from the server being certified, but it can't get a revocation that way because nothing forces the server provide the revocation. To do revocation you have to have a database of all the revoked certificates and check every certificate against the database before accepting it. But there are too many revoked certificates to store on the client; the database is too big. And if the client has to query some server then the attacker can DoS or MITM that server. The best way to handle "revocation" is to fully automate certificate issuance like Let's Encrypt, but then only issue certificates for a short period of time, like 10 days (but renewed every 7). Then you don't have to worry about revocation because the certificate expires in about the same amount of time it would take to be detected and distributed in a revocation database.

fpgaminer 12y ago
Seems like a bloom filter may work to deal with the large database of revoked certificates.
- AnthonyMouse 12y ago
  Bloom filters have false positives. Then you need some way to verify that a hit isn't a false positive, and whatever method is used for that will have the same availability problem in verifying a hit in the bloom filter as it would have in obtaining the revocation that way to begin with.
PeterWhittaker 12y ago
There is another solution, the CRL Distribution Point, or CDP. Entrust implemented this rather elegantly in their product starting in the mid 1990s and still use it today. Instead of having a monolithic CRL, the CA publishes smaller CRLs and writes the CRL location on which a certificate would appear if revoked in the certificate itself. In other words, every X certificates, the CA creates a new CDP, call it CDP_n, and all subsequent certificates issued between now and +X from now have the location of CDP_n written in them: That's where you look for their CRL. +X certificates from now, the CA creates CDP_n+1 and starts writing that into the certs. The size of X can be set, tuned, based on certificate lifetimes, number of users, etc., etc. If you want your CRLs to be fresher, use a smaller X, have more CDPs. The other nice thing about the CDP is that it ties the CRL retrieved from wherever (an LDAP repo, a web site, etc.) to the certificate: The certificate contains within its signed payload a reference to the CDP location and the CRL contains within its signed payload a reference to the same location (the issuingDistributionPoint) so you have a high integrity check that the CRL being used to verify the certificate is actually the right one, even if the certificate is valid and therefore not listed thereupon. This prevents an attacker from fooling you into trusting a revoked certificate by replacing its CRL with one that doesn't match it: The replacement CRL will have the wrong iDP, one that does not correspond to the CDP in the cert.
wiml 12y ago
> only issue certificates for a short period of time, like 10 days (but renewed every 7) That's essentially the situation we're in with OCSP stapling, if you consider the certificate plus OCSP response to be the certificate. (The "must staple" cert extension[1] would make it even more similar.) [1] https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeatur...
- AnthonyMouse 12y ago
  Someone please tell me why doing it that way is better than the following: You validate yourself in the usual way and present a CSR to the CA. The CA signs the certificate but only with a very short expiration. However, unless the certificate is "revoked", you can come back at any point and the CA will automatically sign an identical certificate with the sole exception of the expiration date. (Then maybe they stop after e.g. two years unless you validate again, to keep an "actual" expiration.) The advantage of that over OCSP stapling is that it requires zero modification to the client. What advantage does OCSP stapling have over that?
itistoday2 12y ago
> The best way to handle "revocation" is to fully automate certificate issuance like Let's Encrypt, but then only issue certificates for a short period of time, like 10 days (but renewed every 7). Then you don't have to worry about revocation because the certificate expires in about the same amount of time it would take to be detected and distributed in a revocation database. That can make it less likely that your certs will be used in revocation attacks. It does absolutely nothing to protect your visitors from other compromised certificates. The "best" known way (to my knowledge) is to use a blockchain, which doesn't have the revocation problem. Here is a comparison of a blockchain-based approach I'm working on with some other folks called DNSChain to other approaches people have suggested: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md https://github.com/okTurtles/dnschain/blob/master/docs/Compa...

wolf550e 12y ago

Read Adam Langley's blog about revocation. Only 19.9% of secure sites currently support OCSP stapling [1]. 1 - https://www.trustworthyinternet.org/ssl-pulse/ https://www.trustworthyinternet.org/ssl-pulse/