Slashdot Mirror

← Back to Stories (view on slashdot.org)

Firefox 37 To Check Security Certificates Via Blocklist

Posted by timothy on from the making-a-list-pushing-it-multiple-times dept.

An anonymous reader writes The next version of Firefox will roll out a 'pushed' blocklist of revoked intermediate security certificates, in an effort to avoid using 'live' Online Certificate Status Protocol (OCSP) checks. The 'OneCRL' feature is similar to Google Chrome's CRLSet, but like that older offering, is limited to intermediate certificates, due to size restrictions in the browser. OneCRL will permit non-live verification on EV certificates, trading off currency for speed. Chrome pushes its trawled list of CA revocations every few hours, and Firefox seems set to follow that method and frequency. Both Firefox and Chrome developers admit that OCSP stapling would be the better solution, but it is currently only supported in 9% of TLS certificates.

29 comments

  1. There has to be a better way. by Anonymous Coward · · Score: 0

    Seems like this is a half ass solution. I'm starting to think the whole system is flawed.

    1. Re:There has to be a better way. by Anonymous Coward · · Score: 0

      From the summary:

      “Both Firefox and Chrome developers admit that OCSP stapling would be the better solution, but it is currently only supported in 9% of TLS certificates.”

      So unless you think Firefox and Chrome devs should dictate security policy for every entity and government in the world

    2. Re:There has to be a better way. by Trepidity · · Score: 1

      A surprising number of things are starting to rely on these curated lists to handle "most" cases. The valid-key flip-side of this key blocklist is the public-key pinning list, which is also pretty half-assed.

      With a different (non-crypto) bit of web technology, there's also the mess of how to determine what the "real" domain of a site controlled by an entity is. E.g. in the UK, a domain like example.co.uk is a third-level domain, but is conventionally treated as domain 'example' with suffix '.co.uk', not as domain 'co' in TLD 'uk', and subdomain 'example'. Whereas in dot-com, a domain like foo.example.com would be treated as domain 'example' in TLD 'com', with subdomain 'foo'. How to tell which is which? Yes, some human maintains a giant list, which browsers all build in.

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    3. Re:There has to be a better way. by Anonymous Coward · · Score: 0

      Does public key-pinning support pinning to a specific CA? Google.com returns different public keys all the time, but all signed by the same Google CA. I can get a different cert just be refreshing, I assume because the request gets handled by a different node. Google certs are set to expire after 30-90 days in many cases. Pinning could get annoying when one assumes certs are throw-away.

    4. Re:There has to be a better way. by arglebargle_xiv · · Score: 1

      Seems like this is a half ass solution. I'm starting to think the whole system is flawed.

      Starting? What would it take for you to realise that the whole browser PKI mess is the steaming pile of dung that it actually is?

  2. Whitelist by Anonymous Coward · · Score: 0

    Shouldn't this be a whitelist?

    1. Re:Whitelist by Anonymous Coward · · Score: 0

      No.

    2. Re:Whitelist by Anonymous Coward · · Score: 0

      The TLS certs already are.

  3. Standards by ledow · · Score: 3, Insightful

    "The prescribed global standard doesn't work so we're just going to roll our own. Twice."

    Great. Thanks for that. Not "we will penalise sites that don't allow OSCP pinning because we think it's necessary" but "bugger this, we'll apply our own definition of what can be trusted or not to every user"

    1. Re:Standards by Virtucon · · Score: 2

      unfortunately this is what happens when things like OSCP aren't fully implemented. It's a case of great intent and I'd consider it disposable down the road.

      --
      Harrison's Postulate - "For every action there is an equal and opposite criticism"
    2. Re:Standards by Luthair · · Score: 1

      The issue is that security features are hampering performance, hence each browser is attempting to strike a balance that they feel is palatable.

    3. Re:Standards by Anonymous Coward · · Score: 1

      Firefox & Chrome: “That's it! We're adopting the prescribed global standard. Broken sites need to be fixed!”

      Users: “Hey! A bunch of my sites are breaking? They work in Internet Explorer, Safari, and Opera. Firefox and Chrome must be broken. Time to switch browsers!”

    4. Re:Standards by Lennie · · Score: 1, Insightful

      "The issue is that security features are hampering performance"

      This is not always true (especially in this case).

      OCSP stapeling is faster than normal OCSP.

      (as a side note SPDY or HTTP/2 only works with HTTPS/TLS in practice and is faster than HTTP and in many cases faster than HTTPS. Obviously TLS and even TCP on the server need to be properly configured for that as they a large number of optimizations which might not be enabled by default: https://istlsfastyet.com/ )

      The summary and many commenters here are also wrong/confused about what is going on.

      OCSP is a protocol to ask the CA over HTTP the status of a certificate. The CA then creates a OCSP-response which is timestamped and signed by the CA.

      Every time you visit a HTTPS-website and the browser hasn't done a recent check of the OCSP-status it will ask the CA for such a status. It will ask if the certificate the webserver uses is still valid.

      This means extra TCP-connections, extra DNS-lookups, extra HTTP-request, time at the CA to create that response. And even some loss of privacy (the CA and any network between you and the CA obviously now can see the site you are visiting !). This also means the CA get a lot of requests to handle and the CA is becomes a single point of failure. Vulnerable to DOS-attacks

      The solution to this problem is to have the webserver request an OCSP-response from the CA at a certain interval.

      Now when your browser connects to the website the webserver can include the timestamped OCSP-response in the negotiation protocol. Thus the browser doesn't need to contact the CA itself.

      Thus if all webservers do this, the CA will not only not be a single point of failure any more, but also not have to create that many OCSP-responses speeding up that operation for any remaining sites.

      Now why do Firefox and Chrome include an extra blacklist ?

      This is because pretty much every CA included in the browser uses 'intermediate certificates'.

      Thus a certificate chain looks like this:

      - CA-root-certificate
      - intermediate certificate
      - website-certificate

      The browser includes a copy of only the root certificate.

      It doesn't know which intermediate certificates are valid. It needs to do a seperate OCSP-request for that.

      And OCSP-stapling protocol sort of has an unfortunate 'flaw', it can only include a single OCSP-response when setting up a TLS-connection.

      So what do the browser vendors do:
      - include the root-certiciate
      - include a automatically updating blacklist of revoked intermediate certificates
      - support OCSP-stapling so they know that website-certificate is still valid.

      Now you know why this is done.

      And now to get back to the performance: OCSP-stapling is faster than contacting the CA directly and including a blacklist of revoked intermediate certificates is also faster than contacting a CA directly.

      --
      New things are always on the horizon
    5. Re:Standards by Anonymous Coward · · Score: 0

      Well considering the majority of users cannot understand what can be trusted or not, yeah I think it is okay for them to take that assumption. Especially in the case of sites not implementing OSCP-Stapling.

      Websites and the admins who run them in the majority case take the path of least amount of work to get junk online. The admins, the ones getting paid to do a job that includes security, are the ones not doing the part of their job that includes security. Now there are a range of reasons for that, either the person is getting paid crap and doesn't care, the person honestly doesn't know and has no right having the job they have, the job was contracted out to a third party and the third party just doesn't give a shit, and so on...

      However, the point being is that in theory we've got a modestly good (could be better) system in place. However, when you take that in put it to the real world, web admins collectively suck and consistently expose the public to huge security risks. Firefox and Chrome are doing what they can to mitigate that risk, but hell let's be real here, the web is just not freaking secure and that's either a function of the people getting paid to secure it not doing their job, some sort of management fuckery, or a combination of the two.

      But sitting their and saying that end users can be trusted is just being stupid. End users are the person you should least trust. And we're not talking, "oh well 10% of the users know what they are doing." No we are talking about, "well 0.1% of the users know what they are doing." You're mad if you think a company is going to code for one-tenth of the target audience.

    6. Re:Standards by arglebargle_xiv · · Score: 1

      "The prescribed global standard doesn't work so we're just going to roll our own. Twice."
      Great. Thanks for that. Not "we will penalise sites that don't allow OSCP pinning because we think it's necessary" but "bugger this, we'll apply our own definition of what can be trusted or not to every user"

      The reason for using this alternative to the alternative is because any kind of blacklist-based security doesn't work. It rates #2 in the six dumbest ideas in computer security, with default-allow (which arguably is the problem that blacklists are trying to deal with) at #1. First there were CRLs, which don't work. They were replaced with OCSP, which doesn't work. Now we have cert blacklists, which are fairly recent so they haven't failed often enough for it to be obvious to everyone that they don't work, but give it time...

      Once they fail, the browser vendors will come back with version 4 of the dumbest idea, then version 5, and then version 6, and they'll just keep on doing the wrong thing over and over and over until eventually it starts working, dammit!

  4. Feels like a security hole. by Anonymous Coward · · Score: 0

    So, rather than trusting an external authority, the new authoritative list of "which certificates remain valid?" is stored locally. Feels abusable. If you're just a griefer, seems "not hard" to "revoke" some real certificates and play havoc. If you're more malicious, you could "unrevoke" some legitimately revoked certificates, which (combined with using those compromised certificates to sign fake certificates) could be used for MITM.

    1. Re:Feels like a security hole. by Pi1grim · · Score: 1

      If you have access to cert storage you can do all kind of tricks like adding CA-s or removing them. So "adding to blocklist" is like frying ants with 50megawatt laser.

  5. Comodo blacklisted? by Anonymous Coward · · Score: 0

    I've noticed that tor browser now rejects all comodo certs after the superfish mess. I get warnings for every site that uses a comodo cert when using tor browser 4.0.4.

  6. THIRTY SEVEN???? by Anonymous Coward · · Score: 0

    IN A ROW??

  7. Great... by Anonymous Coward · · Score: 0

    just lock more users out of their hardware 'cause the Supreme Mozilla Security Council has decided to block duplicate serial or other certs they deem unworthy (without the option to override, of course...).

  8. Icon by puddingebola · · Score: 3, Insightful

    I think the icon for this story should be Firefox and not Chrome.

    1. Re:Icon by Anonymous Coward · · Score: 1

      Maybe a hidden message there.

    2. Re:Icon by Anonymous Coward · · Score: 0

      Looks like the Slashdot editors stumbled upon an hidden gem of truth by chance.

  9. That's great, but will they do it over HTTPS? by Anonymous Coward · · Score: 0

    Totally serious. Previous versions of firefox (and as far as I know, current versions -- I haven't checked in over a year) download the CRL over plain old HTTP.

    Way to make something bordering on useless against the attack in question, mozilla

  10. Another shortsighted decision by Anonymous Coward · · Score: 0

    These guys should be told that malware can modify the browser binary if they really want to insert their crap and will do so if no other means are possible.

    If they were only after protection from scripting, they could've used some captcha-style protected runtime switch for this (and yes,there are ways that require real intelligence). I guess they want also to kill the practice where people are instructed to turn off the feature.

    Another similarly idiotic decision, jointly taken by Mozilla and Google, is to pretend that HTTP/2 protocol requires SSL(TLS) - which it does not. This kind of partial support will kill the protocol for most of the internet (and of course they are planning to drop SPDY so that there is no modern alternative either..).

  11. Mostly mute by Martin+S. · · Score: 1

    This is mostly mute given the single process model used by Firefox is deeply flawed from a security perspective.

    1. Re:Mostly mute by Anonymous Coward · · Score: 1

      That's "moot" not "mute'. The single process model has worked thus far despite the naysayers. However, Mozilla has a multi-process framework in development.

    2. Re:Mostly mute by Anonymous Coward · · Score: 0

      Nonsense. That's neither here nor there. It's another Firefox issue that could have security implications, but it has little if anything to do with this issue. I know we all want to play "implement my pet feature yesterday!" with Mozilla, but let's at least try to stay on topic for once.