Can end-to-end encryption be securely implemented on a web application?

Question

There are a lot of arguments around whether web applications can implement end to end encryption. Most of the arguments against javascript based solutions are centered around the fact that the the communication under consideration is between two parties which uses that web application as a channel for communication. (Example: Webmail - Protonmail, Chat Clients - Whatsapp Web, Telegram Web). The argument says that the server can always serve a malicious javascript and the communicating parties cannot trust that it would not happen.

The question I have is slightly different. The communicating parties here are the end user who accesses the web application on a browser and a final downstream server behind multiple components such as load balancers and WAFs. The threat here is that I do not trust any of the intermediate systems as TLS do get terminated at each of those endpoints.

1. Is there any possible way I can achieve end to end encryption between the end user and the final backend server if the channel itself is not trusted?

I see potential opportunities for MITM in the key exchange even if we use DHE with signed public keys because the JS which is supposed to be performing the signature validation can be manipulated by one of the intermediary systems.

2. Is there any other way to at least partial end to end encryption? [perhaps by segregating the involved systems or by adding detective controls]

Answer 1

There are a lot of arguments around whether web applications can implement end to end encryption. Most of the arguments against javascript based solutions are centered around the fact that the the communication under consideration is between two parties which uses that web application as a channel for communication. (Example: Webmail - Protonmail, Chat Clients - Whatsapp Web, Telegram Web). The argument says that the server can always serve a malicious javascript and the communicating parties cannot trust that it would not happen.

There are ways to improve the trust you can have in the files being received from the service. (for example Subresource Integrity or SRI) You could also add a service worker to validate the files before there loaded. (possibly through a wasm application). the main point is that this is really hard to do correctly and really easy to break if implemented incorrectly.

The question I have is slightly different. The communicating parties here are the end user who accesses the web application on a browser and a final downstream server behind multiple components such as load balancers and WAFs. The threat here is that I do not trust any of the intermediate systems as TLS do get terminated at each of those endpoints.

This effectively means you are at the same point as the others.(you can not trust the chain)

Is there any possible way I can achieve end to end encryption between the end user and the final backend server if the channel itself is not trusted?

Yes, but you need additional steps to make this happen. (for example the final fecrypt is handled outside the browser).

I see potential opportunities for MITM in the key exchange even if we use DHE with signed public keys because the JS which is supposed to be performing the signature validation can be manipulated by one of the intermediary systems.

Is there any other way to at least partial end to end encryption? [perhaps by segregating the involved systems or by adding detective controls]

It all boils done to what level of trust is sufficient in your use case. And what steps do you actively use to control the complete system. (e.a. how do you validate, authenticate and check the integrity of all components at each end (and in the middle for the relevant parts).

Also how do you protect your key information? (you have little to no way of ensuring that the key information will not leak out of the browser unless you take special care about it. Or do you employ something like a smart card?

Tl;Dr, Yes you could. but it takes special measures to do so. in general I would NOT recommend you do this in this manner. Use proper (vetted) tools that are already in use instead.