[0]: https://github.com/openssl/openssl/commit/731f431497f463f3a2...
Revovation isn't perfect and I would not suggest the current status quo is OK but the intermediary approach Chrome takes cannot be trusted as they have now shown.
If Chome will not show our cert as revoked what is the point of revoking the cert? The author has points but the approach Google ie taking is a cure worse than the disease...
Great. Maybe now, when half the internet is already compromised and all our certificates are not worth the bytes they're made of ... maybe we should try to come up with something better.
edit: Actually, this whole heartbleed affair has been quite eyeopening for me, so I'm thankful for that. But it certainly didn't help with the paranoia I feel the last couple of years while using services on the internet.
Why not other ways to rapid-broadcast invalidity in censorship-proof ways, so that a browser encircled by an enemy can quickly figure out something's wrong? (Or, why can't security professionals get around interdiction as effectively as copyright pirates do?)
I'm quite fond of how the SSH host key system works.
Prompt me the first time I see a new key, provide me with supporting evidence (e.g. show me how many people have previously accepted this fingerprint for this domain) and alert me the same way in the future if the key ever changes.
If the 'supporting evidence' was plugin-based then this system could quickly become more user-friendly and trustworthy than the current centralised system can ever be.
There could be plugins to automatically trigger a SMS challenge on first contact with particularly sensitive sites. Multiple competing P2P web-of-trust plugins, plugins that let you follow trust-lists from third parties, etc.
In the current system you rely on a single, very questionable opinion on the trustworthiness of a given certificate. In the new system you'd be presented with a trust-score compiled from a whole range of opinions. The sources of which you chose before-hand.
Of course this approach doesn't include a license to print money for corrupt CA organisations and is not going to happen for that reason alone.
Or are you suggesting every browser will contact many of its personal web-of-trust sources on every secure-connection? Without additional innovation, that seems just as prone to the performance bottlenecks or soft-failure (on stale data or blocked connections) as the current system.
Yes, revoke is broken by design, especially with mobile and Chrome browser. I'd say it's broken everywhere except Firefox with OCSP Hard Fail enabled.
Thanks to this flaw StartSSL business model has become somewhat outdated IMHO with the free certs and paid revocations.
I'm dreaming that we can fix the revocations issue with 24hour valid certificates. Suggested at the end of my post.
But I must be naive on this as it's too simple, just haven't found the flaw in this myself. Yes, it needs technical orchestration, but at least it does not add extra layer of single point of failure for every session.
EDIT: Just finished the OP post and it does indeed also mention "short-lived certificates" in the end as a potential solution.
Short-lived certificates were explored in Towards Short-Lived Certificates http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-shortliv...
Without certificates, SSL/TLS falls apart.
Perhaps a better use of CAs would be to always delegate authority to the domain owner -- we'd only need OCSP for the CAs, and domain owners could issue hour/day-valid certs via a cert infrastructure. That would push a lot of complexity down to domain owners, it would probably lead to a lot of errors in implementation -- but those errors would only affect the domains -- not the main CA trust chain as such.
I'm not sure if that would be an improvement or not -- but at least you could know that if a domain was run correctly, a valid certificate could actually be trusted...
CAs already provide the same trust infrastructure, but due to incentives do not sign delegating certs by default, but typically charge extra for certs that allow the owner of a domain to set up their own internal CA.
DNSSEC only works (reasonably) for TLDs where DNSSEC is implemented, and when DNS resolvers implement checking -- many ISPs don't. Delegating CAs are already part of SSL/TLS.
DNSSEC requires fidling with the DNS information -- delegating CAs, while requiring issuing certs, only require configuration of the various services (web, imap, smtp etc) -- as per usual.
For delegating CAs to improve the security of any given domain -- some infrastructure would be needed to set up an intermediate CA. I guess for small organizations, OCSP wouldn't really be needed, as the CRLs would be small (assuming different CA for public facing services and stuff like personal certs for users). Another option would be to simply roll certificates frequently.
One problem might be that the 0.1% of sites hit by the false positive effectively couldn't use OCSP stapling but Chrome could just first call back to Google as a CRL proxy to avoid making an OCSP request when the site stapled a valid but potentially revoked OCSP response. Then just store that response from Google for current version of CRL in the cache. End result is that the unlucky false positive sites don't have tons of unnecessary (unnecessary as far as the OCSP spec is concerned) OCSP requests going to the CAs and the only thing they would notice is that a new visitior takes 100ms longer to make the first page load.
And through the magic of bloom filters if you wanted to bump the false positive rate down to 1 in 10,000 it only bloats the list to 1.14MB. Furthermore, there are methods to make the bloom filter scale-able such that a client doesn't have to necessarily download the whole bloom filter again if a bunch of elements are added to it and instead just download a portion of the data required for a full update.
The more I think about it the more I wonder why this isn't already in Chrome in some form or another. The only downside is weird networks where OCSP might be filtered, but not https, and access to Google is filtered.
Edit: One thing I feel stupid for overlooking is that Bloom filters aren't cryptographically secure so an attacker could theoretically find a serial number for some CA that would cause a site to always be a false positive but I don't think any CAs are still giving out serial numbers in a predictable way after the MD5 debacle and even if they were it would seem to be impractical to me. The fix would just be do a SHA256 hash of the serial instead of the serial itself.
I got the idea from Squid and the network of caches.[1] That body of experience may be helpful.
For shrinking the size, RLE might work (most entries would be 0), and rsync may reduce bandwidth. It looks like the Squid network just used http requests for refreshes. There's probably a sweet spot for bandwidth, and I'd guess that 90-99% would work fine; you're balancing the size of the continually updated bloom filter vs. the requests for certificates that match it. I didn't worry about false positives, because it could just send an OCSP query in that case.
Your numbers for revocations sounded very low, but I just used crlset-tools[2] and checked, and it's about right. Which is weird, because someone else[3] mentioned a size of "4.107Kb" at version 1567, but that's somehow different - compression, perhaps. I thought I'd heard about CRLs megabytes long, but Google Chrome seems heavily curated re: CRLs.
I'd hash over signatures instead of the oft-predictable serial numbers, as you noted.
[1] http://wiki.squid-cache.org/SquidFaq/CacheDigests
[2] https://github.com/agl/crlset-tools
[3] https://scotthelme.co.uk/certificate-revocation-google-chrom...
> if the attacker still has control of the site, they can hop from CA to CA getting certificates. (And they will have the full OCSP validity period to use after each revocation.)
The solution here is to not allow OCSP stapling to request a new certificate and use a full OCSP check to verify that the cert wasnt revoked.
Systems like Namecoin could serve this purpose marvelously. Powerful devices have direct access to the entire cryptographically authenticated DNS and certificate database. Weak devices can specify whom they trust to provide them with DNS/certificate data, and even those devices get some cryptographic security guarantees thanks to technologies like SPV.
I should be able to choose who I trust, a notary system would allow me to do just that. No central CA systems.
The biggest concern I can see is Identity management, but, as mentioned by Moxie, most of these CA don't do anything close to proper Identity management any more - I have a number of certificates bought from quite a few different CA's all made out to my rabbit, at no fixed address.
Notaries can, of course, do additional verification - they could even advertise this as a premium.
I don't see why this can't be extended to DNS lookup's either. I trust X notaries and pin the results I get, I can choose to trust a majority, or be hyper paranoid and require everyone to agree. No need to run a power hungry blockchain, no single point of technology failure.
Technically, all of that is feasible today. And I imagine we will see a number of different technologies combined to form a proper, decentralised, system.
Do you know if there was a specific reason or were people just not interested/none of the browsers jumped onboard?
How do you figure that Namecoin is a "single entity"?
Namecoin is fantastic in theory, but has the fatal flaw of using Bitcoin: the fastest number cruncher wins. Some would argue that the strength of Bitcoin's tech is that numerous currencies with different genesis blocks can flourish. That doesn't get us anywhere with naming, though.
Dead horse flog: the CA model's problem is that you can't do federated (global) naming and federated trust in the same system.
What's the issue with that? It's reasonable to assume that the good number crunchers will always have more power than the bad number crunchers, and if that assumption ever fails, it's easy to detect and we're simply back to CA levels of security.
TOFU/POP is not an effective model for the web. There are simply too many sites for it to be useful. It's pretty much an everyday occurrence that I go to a site I've never been to before, and certificate pinning won't help at all there.
Does Namecoin actually work like that? If so, is there a similar alternative that doesn't?
Also, certificate "whitelisting" could be a part of the DNS protocol itself (return the IP address of the requested hostname and the hash of its current, valid certificate).
Something has to give. We need to abolish SSL/TLS and migrate to something that isn't broken by design
It's not the Internet, just the CA system. There are better systems for handling trust out there, for example, people have been signing each other's PGP keys at key signing parties for decades.
Ok, so it is just the portion of the internet that involves purchasing things with credit cards and requiring passwords to access sites. The rest of the internet is just fine.
Great. I thought for a moment that the commercial basis of the internet might be in danger. Now to determine what percentage of the internet is not dependent on the CA system.....
Sorry, but after the last few weeks I'll happily accept a little slowness for the security revocation checking provides in the cases where it does work, even if it's not 100% of the cases.
Doesn't mean there are "no" cases where it works. It just means any attacker dedicated enough can work around the CRLs.
I don't see any reason why one should throw the baby with the water. In this case, I just see Chrome guilty of FUD and hiding behind an intractable problem to justify their incorrect position.
See http://en.wikipedia.org/wiki/Two_Generals'_Problem if you want to convince yourself the problem is intractable.
> "In order to end on a positive note, I'll mention a case where online revocation checking does work..."
To deal with captive portals: have an SSL signed 'subdomain.google.com/you_are_on_the_internet' site/page that Google Chrome can use to check to see if it's captive or not. If it's captive, enable soft-fail. If internet access is available, set to hard-fail.
Websites these days are complex, with many (digital) moving parts - the database server(s), the static image server(s), dynamic response server(s), gateway server, probably a memcache server or something similar. If any one of those goes down, the site is unusable. Why then, should the OCSP server going down be considered any differently? Is a black-hat rented bot-net running a DDoS going to care if it's the main gateway server or the OCSP server?
But let's say we do consider disabled OCSP servers to be a client-side issue. Google could query and cache the OCSP server status, either with OCSP stapling or via some side-channel they build into Google Chrome.
The combination of both would allow hard-fail to be an option in Google Chrome.
Everyone does soft-failHowever what I meant to suggest is a third option. Something like hard-fail with a latch. The client should opt to fail but give the user the choice to proceed.
This would seem more desirable than the current soft-fail implementations when seem to be entirely silent to the end user.
Edit: I get it, I missed that for sites where the key has been changed the stolen key no longer allows such eavesdropping. Thank you to yuhong for helping point this out rather than just laughing at my ignorance while pushing me down the page.
X.509 certificates bind a public key and a human recognizable string (a "common name") together to create a verifiable digital identity. Over-simplified, X.509 is about solving the "I'm Spartacus" problem.
CRLs solve the "He was Spartacus" problem. I agree with the broad conclusion that CRLs aren't effective for human trust, but they are perfectly reasonable for machine trust.
Why didn't the author mention Kerberos? The default lifetime of a Kerberos ticket is designed around humans: roughly the length of a work shift in front of a computer terminal.
final edit: meta-moderation is hard
Name != Identity
It's nearly impossible to have a meaningful English conversation about these problems without getting that straight.