0

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.

  1. Is there any other way to at least partial end to end encryption? [perhaps by segregating the involved systems or by adding detective controls]
1
  • @kelalaka That doesn't seem to address my specific question.
    – hax
    Jan 16, 2020 at 15:44

1 Answer 1

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.

3
  • SRI would not work as the MITM can manipulate the hash as well,
    – hax
    Jan 16, 2020 at 13:16
  • SRI would be 1 step in the layering. you would need to validate the initial html page through other means. Also manipulating the SRI on the fly when employing a multihash starategy is doable but not easy. for a state adversary its easy. but a "run of the mill" criminal they will just go to someone else thats easier to infect.
    – LvB
    Jan 16, 2020 at 13:29
  • What's a mutihash strategy?
    – hax
    Jan 16, 2020 at 13:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .