For those, like me, wondering who the author might be, it appears to be this guy: "Adam Langley works on both Google’s HTTPS serving infrastructure and Google Chrome’s network stack. From the point of view of a browser, Langley has seen many HTTPS sites getting it dreadfully wrong and, from the point of view of a server, he’s part of what is probably the largest HTTPS serving system in the world - See more at: <a href="http://www.rsaconference.com/speakers/adam-langley#sthash.HMdxPRI7.dpuf"" rel="nofollow">http://www.rsaconference.com/speakers/adam-langley#sthash.HM...</a>
So this complete infrastructure is crap. OpenSSL, a software half the internet uses but no one cares about because it's crap. CA's not revoking keys even though they know they're compromised. Revocation being worthless because it's too much of a hassle for anyone to bother.<p>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.<p>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.
Still seeing lots of explanation about why the current system sucks, and not much about how a more robust system might be created and promptly adopted. Langley (the author) mentions short-lived certificates (either rapid expiration or via a 'must staple')... how soon can we enforce that? How short can that make the danger-period where the CA, and Google, and the "connected web" all know that a certificate is invalid, but a user-at-risk does not?<p>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?)
My quick write-up on this from few days ago, <a href="http://www.ahtik.com/blog/startssl-revocation-fees-will-not-matter-and-ssl-certs-are-funky_u1g8E/" rel="nofollow">http://www.ahtik.com/blog/startssl-revocation-fees-will-not-...</a><p>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.<p>Thanks to this flaw StartSSL business model has become somewhat outdated IMHO with the free certs and paid revocations.<p>I'm dreaming that we can fix the revocations issue with 24hour valid certificates. Suggested at the end of my post.<p>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.<p>EDIT: Just finished the OP post and it does indeed also mention "short-lived certificates" in the end as a potential solution.
I think the author is a little disingenuous with the term "security theatre". Basically he argues that OCSP doesn't work because hard fail might cause DOS -- but fails to conclude that without OCSP SSL/TLS <i>is useless</i>. It's a long argument for saying that the CA system is broken (you can only trust the white-list chrome provides) -- and the sensible conclusion is that <i>you cannot trust any other certificate chains</i> (without OCSP) is left out.<p>Without certificates, SSL/TLS falls apart.<p>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.<p>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...
Just make sure you still check revocation of code signing certificates. Otherwise you will end up running malware that is signed with a legit key they got off my stolen Windows laptop.
This argument only holds if the attacker controls every internet connection you use. If you're on a portable device or you're otherwise connecting through various networks, only a subset of which are compromised, revocations are still useful.
When I hear these arguments, I always look for what is wrong with OCSP Must Staple. The author says that at the bottom it might be a solution with short lived certs, but I dont see the need for super short lived certs, only short lived OCSP staples. The author presents this as the problem:<p>> 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.)<p>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.
I'm honestly kind of surprised how little action there has been to assist with a migration away from the CA model. The technology is there, but people just don't seem interested enough to leverage it.<p>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've wondered many times why OCSP isn't distributed as DNS is. When we talk about websites, surely there's no more than one certificate per hostname (or less, i.e. wildcards). I don't think we're talking here of something impossible to do or not feasible with our current technology and computing power.<p>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).
It seems the only problem with hard-fail is the risk of DoS attacks by targeting OCSP servers. However, if you include OCSP stapling you won't be affected. So a solution may be to encourage all users to enable revocation checking with hard-fail, and all servers to support OCSP stapling.
It sounds like the internet is broken Without CRL/OSCP we cannot truly trust that we are securely communicating.<p>Something has to give. We need to abolish SSL/TLS and migrate to something that isn't broken by design
I am thinking that a HSTS option enabling hard-fail OCSP plus OCSP stapling is probably a good idea, though probably less secure than putting it in the certificate.
Let me get this straight. Sites across the internet are (hopefully) revoking their CAs and issuing new ones to address Heartbleed but Mr. Langley is suggesting that we shouldn't check for revoked CAs because it might not do anything and it's slow?<p>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.
Can't the replay attack mentioned in the article be mitigated by using nonces? Why doesn't anyone do this? I'm genuinely confused by this.
The article gives two reasons for why 'soft-fail' is required: Captive-portals, and OCSP server failure.<p>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.<p>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?<p>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.<p>The combination of both would allow hard-fail to be an option in Google Chrome.
Why not hard-fail by default and give the user the option to ignore/override it? Similar to the way other certificate warnings are shown to the end-user.
The author appears to entirely ignore attack vectors where the malicious party can record but not modify/block traffic.<p>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.
I'm having a lot of trouble getting past: "Certificates bind a public key and an identity (commonly a DNS name) together."<p>X.509 certificates bind a public key and a human recognizable string (a "common name") together to <i>create</i> a verifiable digital identity. Over-simplified, X.509 is about solving the "I'm Spartacus" problem.<p>CRLs solve the "He was Spartacus" problem. I agree with the broad conclusion that CRLs aren't effective for <i>human</i> trust, but they are perfectly reasonable for <i>machine</i> trust.<p>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.<p>final edit: meta-moderation is hard