Firefox 37 To Check Security Certificates Via Blocklist

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.

Comments

Standards

[ledow]

"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"

Re:Standards

[Virtucon]

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.

Re:Standards

[Luthair]

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

Re:Standards

[Anonymous Coward]

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!”

Re:Standards

[Lennie]

"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.

Re:Standards

[arglebargle_xiv]

"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!

Re:Feels like a security hole.

[Pi1grim]

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.

Re:There has to be a better way.

[Trepidity]

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.

Icon

[puddingebola]

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

Re:Icon

[Anonymous Coward]

Maybe a hidden message there.

Mostly mute

[Martin S.]

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

Re:Mostly mute

[Anonymous Coward]

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.

Re:There has to be a better way.

[arglebargle_xiv]

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?