Forgot your password?
typodupeerror
Chrome Google Security The Internet Technology

No More SSL Revocation Checking For Chrome 152

Posted by timothy
from the substitute-my-own dept.
New submitter mwehle writes with this bit from Ars Technica: "Google's Chrome browser will stop relying on a decades-old method for ensuring secure sockets layer certificates are valid after one of the company's top engineers compared it to seat belts that break when they are needed most. The browser will stop querying CRL, or certificate revocation lists, and databases that rely on OCSP, or online certificate status protocol, Google researcher Adam Langley said in a blog post published on Sunday. He said the services, which browsers are supposed to query before trusting a credential for an SSL-protected address, don't make end users safer because Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with."
This discussion has been archived. No new comments can be posted.

No More SSL Revocation Checking For Chrome

Comments Filter:
  • Why? (Score:5, Insightful)

    by John Hasler (414242) on Tuesday February 07, 2012 @12:37PM (#38955223) Homepage

    ...Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.

    Why?

    • Re:Why? (Score:5, Insightful)

      by Spad (470073) <slashdotNO@SPAMspad.co.uk> on Tuesday February 07, 2012 @12:42PM (#38955313) Homepage

      Because otherwise (as I've discovered by switching it on in Seamonkey) about 20% of the time the connection to the CRL/OCSP server fails for whatever reason and so your site won't load, even though there's nothing wrong with its certificate.

      Now you might argue that false positives are preferable to ignoring problems, but it does break the user experience pretty badly.

      • Re:Why? (Score:5, Insightful)

        by Imagix (695350) on Tuesday February 07, 2012 @12:53PM (#38955497)

        Now you might argue that false positives are preferable to ignoring problems, but it does break the user experience pretty badly.

        And this is the problem with security. People want the security/safety.... unless it's inconvenient. And yes, there is something "wrong" with the certificate. It is unverifiable as to whether it is still valid. Which you asked it to do.

        • Re:Why? (Score:5, Insightful)

          by Guppy06 (410832) on Tuesday February 07, 2012 @01:17PM (#38955891)

          The real problem with false positives isn't that they are "inconvenient" but that they breed complacency. If 99% of the alerts you get are false, what are the odds you'll actually give enough due diligence to catch the remaining 1%?

          • False warnings (Score:5, Interesting)

            by Firethorn (177587) on Tuesday February 07, 2012 @02:27PM (#38957125) Homepage Journal

            I harp on this constantly. At work, we fairly routinely issue people new certificates and revoke the old ones, even when there's no belief that the certs were compromised. As a result, you can send somebody an email and later that day get new certs. This is a problem because all the digitally signed emails you sent earlier now register as revoked and Outlook proceeds to tell you this, that the email can't be trusted, etc...

            This happens frequently enough that I encounter this 2-3 times a week. The email has always been valid, they just got new certs between their sending the messages and my opening the email(possibly for historical reasons).

            Same deal as with the california cancer warning - stick it on EVERYTHING, and it gets ignored. If you put cancer warnings on apples, they may not pay attention to the cancer warning on that bottle of test chemical.

            • Re: (Score:2, Interesting)

              by Imagix (695350)
              So you're misusing the system, and complaining. When you revoke the old cert, you are stating that it is no longer to be trusted. And now you complain when it says "don't trust this"? I guess a car analogy: (Where I live, you are required to have proof of insurance stickers on your license plate.) You give a properly insured car to your buddy. 2 days later you go and remove the insurance stickers from the car. A week later, your friend is pissed off because the cops gave him a ticket for being uninsu
              • by Firethorn (177587)

                I probably should have said 'they', not 'we'. Thus my harping on the problem - not that I'm anywhere near where I'd need to be to have a chance to be listened to.

                I wouldn't be revoking the certs unless they did something stupid like lost it or gave out their pin.

              • It's still a problem though. You would expect if you revoked a certificate to be able to give a timeframe in which the revocation should be applied (i.e. how long ago do I think it became compromised?)

            • At work, we fairly routinely issue people new certificates and revoke the old ones, even when there's no belief that the certs were compromised. As a result, you can send somebody an email and later that day get new certs. This is a problem because all the digitally signed emails you sent earlier now register as revoked and Outlook proceeds to tell you this, that the email can't be trusted, etc...

              S/MIME is a transport protection, just like SSL. It is not meant to impart non-repudiation on the content of a m

          • The odds are infinitely higher than catching it when displaying no alerts at all.

            • Re:Why? (Score:4, Insightful)

              by Guppy06 (410832) on Tuesday February 07, 2012 @05:04PM (#38959491)

              When was the last time you so much as looked out a window when you heard a car alarm?

              • by Dogers (446369)

                When was the last time you so much as looked out a window when you heard a car alarm?

                The first few weeks after I got a new car..

              • The last time I heard one, which was many, many moons ago. It's not like it costs much to have a look. Just like it doesn't cost much to try again later, or press "ignore" when a CA doesn't respond.

                "Good to know that Google knows, so I don't have to know." Haha.

      • Re:Why? (Score:5, Insightful)

        by kbg (241421) on Tuesday February 07, 2012 @12:58PM (#38955597)

        "CRL/OCSP server fails for whatever reason".

        No it fails because the server administrators for the CRL are incompetent morons. A CRL server is a mission critical server that should stay up 24-7.

        If Chrome and other browsers would simply display an error page with text explaining the problem and point to the offending server, I am sure the problems would be fixed very quick.

        • by Anonymous Coward

          Guessing you have no idea what it takes to keep a server running 24/7. There are thousands of things that can go wrong and bring down a server from simple errors or bugs to Denial-of-service attacks.

          • Re:Why? (Score:5, Insightful)

            by Anonymous Coward on Tuesday February 07, 2012 @01:11PM (#38955791)

            If a CA cannot keep their uptime, they shouldn't be in the business. Part of the fairly high cost of certificate purchases is the fact the CA is going to run multiple, geographically distributed data centers with adequate server coverage. That, or hire a provider that has is ready/willing/able to do this.

            It is just like banks -- if a bank's server failed causing a loss of transaction info for a period of time, nobody would care how hard it is to have 99.999% uptime -- the bank failed in its duties regardless of the reason (hardware failure, Internet issues, security issues, etc.) This is just the same with CAs and revocation.

          • by xorsyst (1279232)

            Oh come on, it doesn't have to be a single server. Plenty of web businesses are able to manage 24-7, it's not outside the wit of man.

          • by rioki (1328185)
            If twitter can run their servers at something like 99.999% then a CA can too...
          • by Joce640k (829181)

            Given how much they charge for certificates they ought to be able to set up a decent server + backup server.

          • by rainer_d (115765)
            A CRL is basically a flat file. It should not be difficult to make it available 24x7 - at least for someone who charges outrageous amounts of money in exchange for basically digitally signing a couple of bytes.
          • by Chrisq (894406)

            Guessing you have no idea what it takes to keep a server running 24/7. There are thousands of things that can go wrong and bring down a server from simple errors or bugs to Denial-of-service attacks.

            Well people running other services (Internet trunks, DNS, many webistes) manage it. Granted it costs money, but I think this validates Google's action; either it should work and be used or don't bother

        • by SETIGuy (33768)

          A CRL server is a mission critical server that should stay up 24-7.

          In order for that to happen you'll need a significant monetary incentive based on uptime. Without that you're going to get a server that's up most of the time.

          • by neonKow (1239288)

            How about, "if your CRL isn't available, our browser rejects your cert and people can't get to sites that you sign?" Who is going to pay for certs at the same CA next year if your CA goes offline that it interferes with their customer base?

            The monetary incentive is already there. Google is removing that incentive.

            • Google is removing that incentive.

              Sounds like "Chrome and most other browsers" have already removed that incentive.

        • by javelinco (652113)
          Perhaps they mean that the connection to the CRL/OCSP server fails for some reason? Fact is, there are a LOT of reasons why getting a response might fail, that has absolutely no relation to whether the server is up or not. There are Internet routing issues for the ISP of the servers (that should be able to be handled). There are routing issues for the users of the browser. There are hacks on the users' system that prevent hitting that site. There are intermittent issues with connectivity due to commun
      • Re:Why? (Score:5, Insightful)

        by Hentes (2461350) on Tuesday February 07, 2012 @01:31PM (#38956141)

        They could load the site and simultaneously display a small warning, thus letting the users decide whether they want to trust it or not. Loading an untrusted is not a tragedy by itself.

        • Re:Why? (Score:4, Insightful)

          by Joce640k (829181) on Tuesday February 07, 2012 @02:13PM (#38956881) Homepage

          At the very least don't display the padlock icon as if everything is cool.

          (Also, keep retrying the certificate request to see if it succeeds. Change the padlock color when it does).

          • Maybe also have the padlock be an animation like the "page is loading" icon. A padlock trying to lock closed.

            Anyway, mu. The Certificate Authority infrastructure is fundamentally broken. Faulty by nature. Fussing with CRLs matters little when your browser already trusts a dozen discount CAs who either are not reporting break-ins or aren't even noticing them.

      • Right, you're saying that only about 20% of the sites that fail the security check are legitimate? So it makes sense to ignore the check in the remaining 80% of sites that contain malware and phishing setups. That's crazy.
      • by sjames (1099)

        I would think the best compromise is to treat inability to connect as passing unless configured to be paranoid.

    • by nedlohs (1335013)

      Why not read the blog post?

      Or if you are too lazy to click a link think about it for a second. Hint: should every site with an SSL cert from X not work because X is unreachable for whatever reason right this second?

      • Re:Why? (Score:5, Insightful)

        by Richard_at_work (517087) <richardprice@nOSPam.gmail.com> on Tuesday February 07, 2012 @12:49PM (#38955423)

        Yes. Because if you are in a MITM position to inject your own compromised cert for site Y, then you are also in the perfect position to deny access to the cert validation servers to stop the validation happening.

        The solution is more resilient servers and services, not eliminating the checking.

        • Re:Why? (Score:4, Insightful)

          by vlm (69642) on Tuesday February 07, 2012 @12:56PM (#38955553)

          The solution is more resilient servers and services, not eliminating the checking.

          Such as, say, having the Mighty GOOG distribute that "CRL in all but name". Which brings us full circle back to the original article, and what they're doing.

        • by nedlohs (1335013)

          And that isn't what the guy is suggesting, because???

      • Re:Why? (Score:5, Informative)

        by Baloroth (2370816) on Tuesday February 07, 2012 @12:57PM (#38955589)

        Hint: should every site with an SSL cert from X not work because X is unreachable for whatever reason right this second?

        Yes. Anyone conducting a MITM attack is practically necessarily in control of the users network, and will just block access to the CRL, which means they will never stop MITM attacks unless you do exactly that. And yes, I know that is the point of the change. My point is: they choose the wrong fix. Sites should only be listed as trusted if the browser really knows they can be (so far as possible, of course). Being "Secure" should meet a minimum standard, and failing that standard means the site should not be listed as "secure", but most browsers do. Choosing to simply ignore part of the established SSL standard is not the solution.

        Opera does precisely this. It still used HTTPS (I think), but it doesn't list the page as being secure, since the page really has exactly the same security as any non-https site (for trust purposes).

    • Convenience. Users care more about convenience than security, so if a browser actually takes action on OCSP or CRL issues, the user will just switch to a competing browser that does not.
    • by microbee (682094)

      Because you don't RTFA

  • Given the painful uselessness of CRLs as presently implemented(we obviously need some way of revoking the things; but the present one is agonizingly broken), I'm just not too sad about the prospect of no longer telling Verisign every time I visit one of their SSL-cert customers(the same is true of all the other certificate mongers who publish CRLs)...
  • What? (Score:4, Interesting)

    by OverlordQ (264228) on Tuesday February 07, 2012 @12:40PM (#38955279) Journal

    He said the services, which browsers are supposed to query before trusting a credential for an SSL-protected address, don't make end users safer because Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.

    So he admits Chrome is broken, so he doesn't fix it and blames the CA's . . makes sense.

    Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch.

    So basically he wants CRLs? I thought he didn't want CRLs?

    • Re:What? (Score:5, Informative)

      by Kohenkatz (1166461) on Tuesday February 07, 2012 @12:51PM (#38955467) Homepage Journal
      What he wants is CRLs stored on the local machine instead of querying a web service.
      • CRLs are revocation lists which used to be published by CAs and clients were able to periodically download.

        As a concept they were replaced with OCSP (online certificate status protocol). Here the client requests the current status of a certificate each time they are presented with it. The idea was that it would be more timely and up to date and meant CAs didn't need to publish a complete list of revoked certificates.

        Now it seems Chrome wants to go back to a bodged version of the old way of doing things wh

    • Re:What? (Score:5, Informative)

      by vlm (69642) on Tuesday February 07, 2012 @12:53PM (#38955495)

      So basically he wants CRLs? I thought he didn't want CRLs?

      Not want CRLs distributed from sites no one cares about.

      CRLs fail unlocked, so to speak. So if you can't pull a CRL from a CA the browser goes on its merry way. So if you're pulling a MITM attack using a known compromised cert, "everyone knows" you just block access to the CA. End users will never notice. 99.9999% of end users will never visit anything with a *.verisign.com domain.

      However, if you block access to www.google.com or plus.google.com or gmail.com because they're distributing a meta-CRL THEN "most" users will notice the might GOOG is dead.

      So you start with a web of trust where no one cares if any of the threads are cut. Thats not gonna work. So how bout piggybacking the web of trust on top of a Very Popular Site. Being a GOOG guy (I think?) he suggests his employer, although I know of no technical reason why itunes.apple.com or microsoft.com couldn't also distribute CRLs.

      Now if you want to pull a MITM attack its not enough to null route the CAs, you can't null route the Mighty GOOG without the users noticing, so you have to do something much more sophisticated to block access to the most recent CRL.

      The funny part is now all the noobs who report internet outages as "google is down" are going to have to wonder, is someone trying to pull a MITM or is it just noob-speak for an internet outage...

      • CRLs fail unlocked because that's what the browsers set as the default to avoid inconvenience.

        Now, if the CRLs are local, will they still fail unlocked if they're missing or corrupt? i.e. next virus target.

        If so, then they've done nothing to help the fundamental problem of insecure security.

      • 99.9999% of end users will never visit anything with a *.verisign.com domain.

        There are over 2 billion internet users... so you're saying only 200 people in the world will visit that site? Is now a bad time to note that millions of websites have a 'Verisign Approved' widget on their site that has a referred URL back to the *.verisign.com domain?

        • by Kalriath (849904)

          Not for long, come Q2 this year that becomes "Norton Secure" and links back to norton.com.

    • by Baloroth (2370816)
      He doesn't want CRLs. Chrome (and many other browsers) already use these kinds of blocklists, so basically he just wants to not use CRLs at all.
    • by thue (121682)

      > So he admits Chrome is broken, so he doesn't fix it and blames the CA's . . makes sense.

      If the CAs' blacklists worked reliably, then chrome wouldn't need to ignore when they were down. So it is the CAs' fault.

    • by Jonner (189691)

      He said the services, which browsers are supposed to query before trusting a credential for an SSL-protected address, don't make end users safer because Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.

      So he admits Chrome is broken, so he doesn't fix it and blames the CA's . . makes sense.

      Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch.

      So basically he wants CRLs? I thought he didn't want CRLs?

      You've made the classic mistake of taking the Slashdot headline seriously. The actual post [imperialviolet.org] doesn't say Chrome will stop using CRLs. It says they will be pushed to Chrome directly from Google. No one "admitted" that Chrome is broken. The entire system is broken. All major browsers will load an HTTPS site even if they cannot get the CRL via OCSP because doing otherwise would cause huge amounts of unnecessary breakage and just make users angry and confused. From the actual post:

      So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.

  • Great idea. (Score:3, Insightful)

    by Targen (844972) on Tuesday February 07, 2012 @12:41PM (#38955305) Homepage

    Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.

    And the solution, obviously, is not checking at all. Slick.

    • by mlts (1038732) *

      I'm guessing the fact that a top level certificate compromise is something that is to be ignored. We already went through this with a CA that got bankrupted due to security issues. Web browsers not dealing with revoked keys will just add significantly to the time that blackhats can MITM stuff.

      The solution? I would say that SLCs (short-lived certificates) might be the best thing, with a mechanism to replace browser root keys periodically. Every time the browser is updated, CAs have new root keys. This w

      • by Chryana (708485)

        This doesn't look like a bad idea... But the thing is, Google wants to get rid of on-the-fly verification of revocation certificates, and you suggest on-the-fly reception of short lived certificates, so it might run into similar issues as the current system. Remember, a revocation list is permanent, so you can just download the latest updates to it, which should not be too bandwidth intensive if you do it every time you start your browser. A list of active certificates could not be kept, and would have to b

    • No, the solution is checking at update time and storing the list of revoked certs locally so that you don't need to rely on the CLR server being available (which is something a man in the middle would be able to disrupt anyway).

  • It's so easy to turn the Internet into whatever you want it to be, when you're the largest advertiser, largest service provider, largest search engine, largest content provider, software maker, hardware-platform-vendor, and even an ISP.

    Have we reached the point where google's "too big to fail"?

    • Re:Being Google (Score:5, Informative)

      by Spad (470073) <slashdotNO@SPAMspad.co.uk> on Tuesday February 07, 2012 @12:53PM (#38955517) Homepage

      All they're really doing is moving the certificate revocation checks from the client to the server; Google updates its own CRL and pushes it to Chrome so that the browser doesn't have to rely on potentially unresponsive 3rd party sites for its checks.

      • Re:Being Google (Score:5, Insightful)

        by Ferzerp (83619) on Tuesday February 07, 2012 @01:44PM (#38956407)

        Except now Google is presenting itself as an authority on the status of certificates that it has no business doing so with to the users of chrome.

        This is a bad thing.

        • Re:Being Google (Score:4, Insightful)

          by swillden (191260) <shawn-ds@willden.org> on Tuesday February 07, 2012 @02:43PM (#38957401) Homepage Journal

          Except now Google is presenting itself as an authority on the status of certificates that it has no business doing so with to the users of chrome.

          This is a bad thing.

          Google is already the authority which decides which CAs will be trusted by Chrome. How does it really change anything if Google also collects the CA CRLs and pushes them to the browser? Other than making revocations much more reliable.

    • by Ferzerp (83619)

      This. It should not be within the realm of Google's purview to rewrite standards on an adhoc basis.

  • "Google's Chrome browser will stop relying on a decades-old method for ensuring secure sockets layer certificates are valid..."

    'Decades'? As in more than one?

    The first web browser was made by Tim Berners-Lee in 1991. That's technically two decades ago...but were there secure sockets? Layers? Certificates?

    Yeah, I'm nitpicking. But the web didn't exist publically before 1994 -- I remember formatting HTML for Mosaic back then, as our company tried to keep on top of the bleeding edge. This stuff really wa

  • He's right (Score:5, Informative)

    by HBI (604924) <kparadine AT gmail DOT com> on Tuesday February 07, 2012 @01:03PM (#38955681) Homepage Journal

    CRLs and OCSP are functionally useless. For PKI to work, certificate revocation must work also. Some kind of reliable system has to be constructed. Chrome is doing what they need to do to make this happen by abandoning the useless, outdated technologies of the past.

    Before someone asserts otherwise, explain DigiNotar. While you are at it, explain all the rest of the CA compromises over the last two years. Then explain why each browser essentially had to distribute a patch to fix the problem rather than relying on OCSP and CRLs. If they are functional, that wouldn't have been necessary.

    • Re:He's right (Score:4, Insightful)

      by xorsyst (1279232) on Tuesday February 07, 2012 @01:13PM (#38955823) Journal

      Opera didn't have to distribute a patch, because they use OCSP and CRLs properly. And I've never heard of anyone complaining that it causes a problem.

      • by HBI (604924)

        It's not possible that Opera uses OCSP and CRLs "properly". The simple reason why is that many certificates have no OCSP or CRL specified.

        Can't use what's not there.

        You should probably examine your security posture if you think you are adequately covered by Opera's handling of certificate revocation.

  • But it's not like a local attacker intercepting communication at your end is the only possible option. What if the datacenter the server is hosted in or an ISP along the path has been compromised? What if the target site's DNS has been modified to point to the attacker? There are many possible ways that an attacker could cover only parts of the internet or only the specific target itself, still allowing full access to the CRLs and thus allowing them to do their jobs.

    That said, I can't argue with the priv

    • by makomk (752139)

      What if the datacenter the server is hosted in or an ISP along the path has been compromised? What if the target site's DNS has been modified to point to the attacker?

      What if someone's running a phishing site using fraudulently-obtained EV certificates that display a nice pretty green message? That's not normally possible because EV certificates normally mandate OCSP checks that fail secure, but with these changes once an attacker gets their hands on one they'll have plenty of time to exploit it...

  • by MobyDisk (75490) on Tuesday February 07, 2012 @01:59PM (#38956665) Homepage

    because Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.

    This is just a case of unsafe defaults. To fix this in Firefox go to Tolls - Options - Advanced - Encryption - Validation and check the box that says "When an OCSP server connection fails, treat the certificate as invalid."

    This is probably what the default should be anyway. I cannot imagine a fingerprint scanner that just assumed everyone was authorized if the database went down. If it can't validate, then it isn't valid!

  • by Culture20 (968837) on Tuesday February 07, 2012 @03:07PM (#38957761)
    Chrome: "We're not wearing eye-gear on the paintball field because we all shoot at torsos"
    Banks: "That's nice. You're not playing on the paintball field without eye-gear."
  • by losttoy (558557) on Tuesday February 07, 2012 @04:53PM (#38959323)
    I have been running with security.OCSP.require set to true for a long time and haven't really noticed failures. Maybe the stated problem with CRL check timeouts is being overblown?
  • by martin-boundary (547041) on Tuesday February 07, 2012 @07:10PM (#38960931)
    I guess even top Google engineers make boneheaded analogies. FTFBP:

    So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.

    A seat-belt isn't there to protect you if you drive at 200mph into the side of a building. If that's what you're doing, your day is going to be ruined no matter what.

    Seat-belts are there to protect against the low hanging fruit of accidents. If you're driving 20mph and the neighbour's cat suddenly runs across the road, you break and the seat belt stops you and your passengers from getting a nasty bruise.

    That's what it's for, and it works exceedingly well at doing that. If we get rid of seat-belts because they don't help in the 1% of cases, like when someone crashes into a building, then all we're doing is increasing dramatically the global accident rate on trivial incidents, like the cat example.

    • by Junta (36770)

      That's what it's for, and it works exceedingly well at doing that.

      The problem is the attacks where it's useless are far more prevalent than the ones where it does any good.

      It only does good if the attacker compromises near the server. This is relatively rare.

      If the attack either comes as a IP layer MITM (attacker is providing a router to victim) or DNS poisoining, then *all* servers including OSCP are fair game.

      The problem with the rant on soft-fail is it ultimately places the fault on OSCP and not on the *soft* aspect of failing and goes on to recommend a blacklist str

  • So I see the practical benefit, trying to reinstate the 'offline' nature so that CA hosting facilities do not become the bottleneck for various things. From a security perspective this seems bad...

    CRL relies upon the CA knowing about all the certs that should be revoked. Notably, if someone managed to discretely get a CA's private key, and applies that advantage with any subtlty, then the certificate isn't even known to be issued by the CA, they can't revoke what they don't know about.

    Compromising an arch

For every bloke who makes his mark, there's half a dozen waiting to rub it out. -- Andy Capp

Working...