5 ms·
Disclosing the private key in this blog post was extremely irresponsible. Although the certificate has been revoked, revocation basically doesn't work[1], so f
by agwa 12y ago
Disclosing the private key in this blog post was extremely irresponsible. Although the certificate has been revoked, revocation basically doesn't work[1], so for practical purposes this key will usable for MitM until it expires on Mar 19, 2016. Hopefully browser vendors will push out updates that explicitly blacklist it (Chrome is pretty proactive about this, not sure about other browsers), but that won't help non-browser clients or users running out-of-date browsers.
If you ever do this, please, please destroy the private key immediately. There are other ways to prove you had possession of it, such as by signing something with it.
[1] https://www.imperialviolet.org/2014/04/29/revocationagain.html https://www.imperialviolet.org/2014/04/29/revocationagain.ht...
- ivanr 12y agoIndeed. Hopefully browser vendors will consider this certificate for explicit blacklisting using their proprietary channels. (I've already asked.)
- utefan001 12y agoDoes anyone know if there is a way to blacklist a certificate on a windows 8.1 machine? To me, managing certificates between the os, IE, Chrome and Firefox is a bit of a joke in 2015. Besides blacklisting, I would love to know of script that will output the certificates that the PC has trusted but are not trusted by Verisign.
- realityking 12y agoBoth Internet Explorer and Chrome use the system's certificate store. So you "only" have to manage the os and Firefox.
- agl 12y agoDone in Chrome with CRLSet 2140.
- mdewinter 12y agoThen shouldn't revocation be fixed?
- AnthonyMouse 12y agoRevocation 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 agoSeems like a bloom filter may work to deal with the large database of revoked certificates.
- AnthonyMouse 12y agoBloom 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
- excel2flow 12y agoBtw, is there any reason why CRLs are not widely published via DNS (https://tools.ietf.org/html/rfc4398 https://tools.ietf.org/html/rfc4398)? It would lower the costs associated with distribution of CRLs...
- agwa 12y agoCRLs are way too large to distribute through the DNS (e.g. the Comodo CRL mentioned in the blog post is 740kb). And what does that RFC say to do when a CRL is too big? Return a URL instead. So we're back to square one.
- excel2flow 12y agoYeah, right. But any CRL smaller then 64 KB can be distributed this way. So it would be CA's responsibility to keep them small, otherwise they would pay for the full traffic. "The RDATA field in the DNS protocol may only hold data of size 65535 octets (64kb) or less. This means that each CERT RR MUST NOT contain more than 64kb of payload, even if the corresponding certificate or certificate revocation list is larger. This document addresses this by defining "indirect" data types for each normal type."
- yuhong 12y agoPersonally, I am for an overridable hard-fail option for OCSP, which should not be the default for now. What I want is an actual interstitial with an override option, because it will show before the HTTP request is sent.
- deleted 12y ago[deleted]