How Cloudflare verifies the code WhatsApp Web serves to users(blog.cloudflare.com)
blog.cloudflare.com
How Cloudflare verifies the code WhatsApp Web serves to users
https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users/
1 comments
At Element we would love to get involved with this too. We urgently need better ways to demonstrate that Element Web hasn’t been tampered with in transit.
We currently use CF as a CDN for hosting Element however; I may be missing something, but: how do you stop CF conspiring to mess with the JS and publish a different hash?
We currently use CF as a CDN for hosting Element however; I may be missing something, but: how do you stop CF conspiring to mess with the JS and publish a different hash?
(I lead privacy products at CF and co-authored the linked post)
This—improving trust in the system and making it provable—is something we're looking to do. Having the publisher sign the hashes and publish the public key is one approach we've discussed. You'd be able to validate this out-of-band. Most users, however, likely won't go to this extent - a lot of the motivation behind this work was around automating the stuff that folks just don't do (like comparing hashes).
Longer term we'd like to get more of these capabilities into the browser itself - comparing the hash in a separate context, validating signatures, etc - so that this is scalable.
Ultimately these systems are also still built on trust: at some level there are humans in the loop, an assumption that the user's machine itself isn't compromised, and/or that the code itself is actually "correct" (for some definition of correct).
This—improving trust in the system and making it provable—is something we're looking to do. Having the publisher sign the hashes and publish the public key is one approach we've discussed. You'd be able to validate this out-of-band. Most users, however, likely won't go to this extent - a lot of the motivation behind this work was around automating the stuff that folks just don't do (like comparing hashes).
Longer term we'd like to get more of these capabilities into the browser itself - comparing the hash in a separate context, validating signatures, etc - so that this is scalable.
Ultimately these systems are also still built on trust: at some level there are humans in the loop, an assumption that the user's machine itself isn't compromised, and/or that the code itself is actually "correct" (for some definition of correct).
It's great to hear that you want this added to browsers themselves, and you're right that browsers are more likely to implement such changes if you can show that users are deliberately installing an extension to add the missing functionality.
There has been some discussion at the W3C about extending the SRI spec in this direction[0], but it seems they are reluctant to do that unless "multiple browser vendors" choose to implement something like this.[1] Hopefully the existence and adoption of this browser extension helps to solve that bootstrapping / Catch-22 problem.
As for usability, would it be sufficient to just adopt a TOFU model, where the browser pins the first key it sees for a domain? To prevent the risk of permanently bricking a site (if the key gets lost, or the host gets temporarily compromised) you could politely warn the user that the key has changed, or just show a different colour icon representing that the code is correctly signed with an unknown key.
[0] https://github.com/w3c/webappsec/issues/449
[1] https://github.com/w3c/webappsec-subresource-integrity/issue...
There has been some discussion at the W3C about extending the SRI spec in this direction[0], but it seems they are reluctant to do that unless "multiple browser vendors" choose to implement something like this.[1] Hopefully the existence and adoption of this browser extension helps to solve that bootstrapping / Catch-22 problem.
As for usability, would it be sufficient to just adopt a TOFU model, where the browser pins the first key it sees for a domain? To prevent the risk of permanently bricking a site (if the key gets lost, or the host gets temporarily compromised) you could politely warn the user that the key has changed, or just show a different colour icon representing that the code is correctly signed with an unknown key.
[0] https://github.com/w3c/webappsec/issues/449
[1] https://github.com/w3c/webappsec-subresource-integrity/issue...
(Feel free to drop me an email - [email protected] - if you want to chat more)
We’re iterating on a standard for this - our current thinking is to use well-known URIs to publish both a public key (is the hash legit?) and hash endpoint URIs for clients to pull.
The extension requirement is an “unfortunate” friction point due to needing a separate security context for hash verification. Doing this part natively will be the biggest adoption win.
We’re iterating on a standard for this - our current thinking is to use well-known URIs to publish both a public key (is the hash legit?) and hash endpoint URIs for clients to pull.
The extension requirement is an “unfortunate” friction point due to needing a separate security context for hash verification. Doing this part natively will be the biggest adoption win.
I would have liked an example of an attack this is supposed to stop.
I assume. something like this, but the article really isn't clear about that: You're using a CDN which got compromised, but your CICD servers haven't and your DNS provider also hasn't been compromise. Therefore by looking at some DNS records the browser cam verify stuff that's loaded within your domain from a 3rd party CDN. Or maybe, your TLS certs were hacked, but not the ones from the Cloudflare hash registry.
TBH those don't really seem like common attack vectors. If you're a state level actor and can fake TLS, the later example doesn't work and if your CDN gets hacked, chances are high this vendor is also your DNS and CI/CD provider...
What am I missing here?
I assume. something like this, but the article really isn't clear about that: You're using a CDN which got compromised, but your CICD servers haven't and your DNS provider also hasn't been compromise. Therefore by looking at some DNS records the browser cam verify stuff that's loaded within your domain from a 3rd party CDN. Or maybe, your TLS certs were hacked, but not the ones from the Cloudflare hash registry.
TBH those don't really seem like common attack vectors. If you're a state level actor and can fake TLS, the later example doesn't work and if your CDN gets hacked, chances are high this vendor is also your DNS and CI/CD provider...
What am I missing here?
> We urgently need better ways to demonstrate that Element Web hasn’t been tampered with in transit.
Serving the content with HTTPS ought to ensure that. What Cloudflare does with WhatsApp is to prove to facebook the user hasn't modified the code locally. This is dis-empowering the user, not protecting the user.
Serving the content with HTTPS ought to ensure that. What Cloudflare does with WhatsApp is to prove to facebook the user hasn't modified the code locally. This is dis-empowering the user, not protecting the user.
> What Cloudflare does with WhatsApp is to prove to facebook the user hasn't modified the code locally.
I don't follow. How does this system:
A) force users not to ignore the hash mismatch?
B) guarantee to Facebook that they haven't ignored the hash mismatch?
C) even communicate to Facebook anything about the hash mismatch? This is a clientside comparison, I don't see anything about reporting to Facebook that hashes mismatch.
My local Linux installation compares hashes for downloaded packages, I don't see how I as a user having more insight into whether or not the packages is corrupted/altered means I'm disempowered.
----
> Serving the content with HTTPS ought to ensure that
That's not what the article is talking about, the article is talking about code being served from a CDN. HTTPS will not protect you from a CDN tampering with your code.
I don't follow. How does this system:
A) force users not to ignore the hash mismatch?
B) guarantee to Facebook that they haven't ignored the hash mismatch?
C) even communicate to Facebook anything about the hash mismatch? This is a clientside comparison, I don't see anything about reporting to Facebook that hashes mismatch.
My local Linux installation compares hashes for downloaded packages, I don't see how I as a user having more insight into whether or not the packages is corrupted/altered means I'm disempowered.
----
> Serving the content with HTTPS ought to ensure that
That's not what the article is talking about, the article is talking about code being served from a CDN. HTTPS will not protect you from a CDN tampering with your code.
I was also a little confused by their comment too, but I assumed they were imagining that the extension would cause the site to fail to load if the user started adding custom scripts into the page somehow. That doesn't mean that any data is sent to Facebook's servers telling them that the user tried to do this, but it would give Facebook confidence that only unmodified web apps are running.
Of course, all this presupposes that the user has to install the extension to use WhatsApp on the web, which isn't the case. However, the extension could theoretically be made mandatory if it contained a load of obfuscated code that the web app was dependent on. That would basically mean implementing a type of DRM in the extension, and maybe there is some way to use EME to achieve that at a lower level.
If a website ever started using techniques like that, then that would be the point at which to complain about disempowering users. Fortunately this plan doesn't do that, as you say, and merely allows users to optionally confirm that they are running the code they requested.
Of course, all this presupposes that the user has to install the extension to use WhatsApp on the web, which isn't the case. However, the extension could theoretically be made mandatory if it contained a load of obfuscated code that the web app was dependent on. That would basically mean implementing a type of DRM in the extension, and maybe there is some way to use EME to achieve that at a lower level.
If a website ever started using techniques like that, then that would be the point at which to complain about disempowering users. Fortunately this plan doesn't do that, as you say, and merely allows users to optionally confirm that they are running the code they requested.
> The system described in this post doesn’t scale to arbitrary assets – yet – but we are exploring ways in which we could extend this offering for something more general and usable like Binary Transparency.
It would be great if other makers of E2EE apps (like ProtonMail and Matrix's Element) joined this initiative and made the verifier work for their web apps too. I'm sure Cloudflare would be happy to partner with those organisations.
For context, there have been a few other attempts in the past to verify the contents of web apps, such as Signed Pages[0] and SecureBookmarks[1], but those have had usability drawbacks. One thing I hope Cloudflare end up supporting is returning the version/hash info from a verifiable append-only log. That way, users can choose to run an old version of a web app until the new version has been around for long enough to be independently reviewed.
[0] https://github.com/tasn/webext-signed-pages
[1] https://coins.github.io/secure-bookmark/