3

I'm making a simple web service that (skipping other details) allows a user to upload a message that can be retrieved by another user but can be decrypted only with a certain key. The message is encrypted and decrypted on the client side and can't be decrypted on the server unless the key is somehow known.

The code of the web page can be reviewed to check that there are no backdoors that would send the key to the server or anywhere else. However, that needs to be checked every time the page is served, because theoretically the backdoor can be added at any time, since what is happening on the server is not transparent to the client. Even if the user reviews the source code of the server side, there is no guarantee that the code has not been modified.

Is there a way to guarantee that the initial page the user accesses has not been changed?

As an example, maybe there is a service where one can upload an HTML page, and the service would be a guarantor that the page has never changed from that moment, then I could redirect my users to that page from that service.

I wish there were some user-friendly checksum kind of thing in browsers for these cases, but from what I understand it is not a thing.

Improve this question
7
  • 2
    If you just want to check if the script has changed (not the whole page), and it has a subresource integrity hash, you can just check that. Commented Feb 15 at 21:56
  • @JohnWu: Subresource Integrity is strictly for checking third-party resources, not resources from the original server. It's useless if you don't trust the original server, because all the hashes come from this exact server. Commented Feb 15 at 23:07
  • Sure, if it's from the original server then it probably won't have SRI on it. If it does have SRI, it can be relied on because the browser does the check. Commented Feb 16 at 1:32
  • 1
    @JohnWu: There might be a misunderstanding of how SRI works. The idea of this feature is that the original server provides hashes of third-party resources (like the jQuery code stored on some CDN). It's then possible for the browser to check whether the resources match the hashes. However, this is all useless if you don't trust the server which provides the hashes. This server can, for example, manipulate jQuery, hash the malicious code and then set up SRI with this hash. To the browser doing the SRI checks, it will look like everything is perfectly fine. Commented Feb 16 at 9:59
  • 1
    Related: security.stackexchange.com/questions/238441/… Commented Feb 16 at 13:59

1 Answer 1

Reset to default
8

Probably the easiest solution to the underlying problem is to delegate all client-side cryptographic operations to a browser extension. Unlike script elements, extensions are manually installed and don't change unless the user updates them (or enabled automatic updating). So they're much more stable and cannot simply be altered from one server response to the next.

Making your users store and validate a checksum of the page content sounds like a bad idea. What if you want to update the page? This doesn't even have to refer to the core crypto code. Maybe you just want to fix a typo or change the layout slightly. It would be silly to turn this into a major problem. Also, the only realistic way to do this check would be a browser extension, which means your users will have to install one anyway – so why not skip all the trouble and use the extension to solve the actual problem?

Improve this answer
3
  • 5
    See engineering.fb.com/2022/03/10/security/code-verify for an interesting read on a browser extension developed by Meta for their WhatsApp web client. The extension allows users to verify the integrity of client-side code, and allows developers to push new updates any time, by using a trusted third party (CloudFlare) to provide the reference hash. Commented Feb 16 at 3:01
  • @mti2935: Good find. I wasn't aware Meta took this approach for WhatsApp. Commented Feb 16 at 10:05
  • 1
    FYI, See github.com/beurdouche/explainers/blob/main/waict-explainer.md for an interesting read on work being done by the W3C, Google, Mozilla and others to implement a method for client-side code integrity verification (similar to that of Meta's Code Verify browser extension) natively in Google Chrome and Mozilla Firefox. Commented Sep 20 at 14:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.