5 ms·
Fingerprinting Firefox users with cached intermediate CA certificates
- JoshTriplett 10y agoThis is brilliant, especially the idea of loading content from correctly configured sites to set bits, loading incorrectly configured sites to test bits, and using an error-correcting code in case the user happens to visit some of the correctly configured sites before returning. The right fix would be to either always fail a site load that doesn't serve the right intermediate certificate, or do what Chrome and IE do and always find and load the intermediate certificate.
- jwilk 10y agoAlways loading the intermediate certificate trades one privacy problem for another. From https://bugzilla.mozilla.org/show_bug.cgi?id=1334485#c11 https://bugzilla.mozilla.org/show_bug.cgi?id=1334485#c11 : Another approach to this problem is to do AIA chasing (that is, fetch the URI in each certificate to attempt to find an issuer). Firefox currently does not do this for performance and privacy reasons. Doing each fetch is slow (you would probably want a cache anyway, and so would still be vulnerable to this attack). Also, a CA (or even an untrusted party, since you can't verify the trustworthiness of the AIA field until after you've already fetched data from it) can use this to track users.
- caf 10y agoAlways failing the load seems like the right approach to me, it would also have the advantage that it makes it easier to see if your site is correctly configured or not.
- JoshTriplett 10y agoAgreed, but if a significant number of websites would suddenly start failing (and only in Firefox), that could break things for too many users. Might require a more gradual transition.
- caf 10y agoThose sites already fail for Firefox users though, right? Just randomly, depending on what other sites they've visited first.
- JoshTriplett 10y agoNot if, for instance, they're domains associated with some main site, such that people have always visited the main site first. Someone looking to make such a change would need some data on whether any such cases exist on prominent sites.
- jMyles 10y ago...or, you know, come up with a key verification system system that isn't completely idiotic. :-)
- progval 10y agoIt reminds me of the HSTS Super Cookie https://github.com/ben174/hsts-cookie https://github.com/ben174/hsts-cookie
- nnx 10y agoLooks pretty bad. Isn't this the first ever cross-device super cookie? "Safari - Especially scary - since the HSTS information is actually persisted to your iCloud account and is therefore retained across devices."
- Tharkun 10y agoIs there a way to clean up cached (intermediate) certs without having to nuke your entire firefox profile?
- jwilk 10y agoI believe removing cert8.db from your profile directory will do trick. (Beware that this will probably remove other certificates, too.)
- Sami_Lehtinen 10y agoI've been asking browsers to provide per tab security isolation for a long time. Would make many of the attacks much less efficient. Each new tab should be clean as well as closed tabs should get destroyed.
- retox 10y agoIs there any impact on the tor browser bundle which uses Firefox?
- jMyles 10y agoHow many uncomfortable side effects need to arise from the CA system before we decide to do key verification in a different way?
- paulddraper 10y agoWhich way?
- Cyph0n 10y agoIs there even a viable and scalable alternative? Genuine question.
- xorcist 10y agoBy using the existing domain allocation system. Sign all delegations of domains, and use this assertion to build TLS trust. As long as TLS certificates sign domain names you trust that delegation, so having an alternate trust root is stupid (and having 391 of them is beyond stupid).
- Cyph0n 10y agoI don't see how that would be a significant improvement though. Firstly, given how many domain registries and registrars there are, there still would be a ton of trust roots (probably way more than 391). Secondly, this would significantly increase the difficulty of managing a domain registrar, and would probably lead to decreased competition in the space (more expensive domains?). And thirdly, the client would still need to manage trusted certificates locally, so client-side complexity is unchanged. Most importantly, the benefits of a new system must vastly outweigh the cost of migrating to it.
- xorcist 10y agoThe registry/registrar system may not be perfect, but that's what we have (and there is an appeals process). It's not as bad as you make it seem. You can not redelegate google.com for example, even if you work at a registrar. Whereas any CA could generate a new certificate, today. As long as domains are what you generate certificates for you might as well assert that delegation in a cryptographically secure way. It may also be a good basis to make domain transfers more secure.
- sjtgraham 10y agoMost browsers will still connect if the leaf certificate has certificate authority information access extensions, the browser can use them to download intermediate CAs, and then construct a valid chain back to a trusted root. Does Firefox not do this?
- jwilk 10y agoFrom https://bugzilla.mozilla.org/show_bug.cgi?id=1334485#c11 https://bugzilla.mozilla.org/show_bug.cgi?id=1334485#c11 : Another approach to this problem is to do AIA chasing (that is, fetch the URI in each certificate to attempt to find an issuer). Firefox currently does not do this for performance and privacy reasons. Doing each fetch is slow (you would probably want a cache anyway, and so would still be vulnerable to this attack). Also, a CA (or even an untrusted party, since you can't verify the trustworthiness of the AIA field until after you've already fetched data from it) can use this to track users.