4 ms·

> The issue with client-side, in-browser encryption is that you cannot audit or trust the software. I agree. A few months ago I experimented on ways [1] to aut

> The issue with client-side, in-browser encryption is that you cannot audit or trust the software. I agree. A few months ago I experimented on ways [1] to automate side-channel verification of JS bundles (and other built assets) while linking them to the sources. It's based on trusting both the public CI/CD server (to reproducibly build the sources as they are obtained from the repository) and the public repository provider (to serve everyone the same sources), which in a FOSS environment is a given (if services like GitHub and Travis are in the threat model, there's not much to be done). It was a PoC/WIP, but it seems there might be a use case for side-channel verification. The threat models for this kind of "mistrust" in built assets (assuming traceability and transparency) would be: - Any kind of MitM (proxy/cache/load balancer) in the path of the assets - Hosting provider being compromised (unlikely but still a probability) - Malicious external content being injected at runtime (XSS, CDN) I'm surely missing more, and I'd love to discuss at lengths about what others may have setup to do side-channel verification (ie: when even TLS and/or the CA chain of trust can't be trusted). [1] https://github.com/47ng/revelio https://github.com/47ng/revelio

the8472 7y ago
Even doing it on a CLI doesn't help since the server might deliver something else to the browser. And if you have dynamically generated HTML then you can't really authenticate it either. To trust an application need in-browser fingerprinting of the whole page as it was served to the user and then pin that fingerprint. Combined with fairly strict CSPs. Also, how do I trust the revelio.json? There's no signature.
- franky47 7y ago
  > Even doing it on a CLI doesn't help since the server might deliver something else to the browser. That is indeed one of the hurdles I encountered, ideally the browser itself should be in charge of verifying these claims (resource integrity helps in this case). > And if you have dynamically generated HTML then you can't really authenticate it either. In the case of SSR/PHP/other means of backend-generation of HTML, yes. I initially limited the PoC to SPAs and deterministic JS bundles. > Also, how do I trust the revelio.json? There's no signature. For now, as I said it's a work in progress, but indeed a way to authenticate the tamper-proof properties of the manifest is necessary. This however brings up the issue of a chain of trust, which is what apparently Tanker is trying to provide with their product. Yet, it raises the question: why should they be trusted ? The commercial viability argument (we don't screw up to stay in business) is not enough IMHO, trust should be based on mathematical proofs, not business rules.

the8472 7y ago

Even doing it on a CLI doesn't help since the server might deliver something else to the browser. And if you have dynamically generated HTML then you can't really authenticate it either. To trust an application need in-browser fingerprinting of the whole page as it was served to the user and then pin that fingerprint. Combined with fairly strict CSPs. Also, how do I trust the revelio.json? There's no signature.

franky47 7y ago
> Even doing it on a CLI doesn't help since the server might deliver something else to the browser. That is indeed one of the hurdles I encountered, ideally the browser itself should be in charge of verifying these claims (resource integrity helps in this case). > And if you have dynamically generated HTML then you can't really authenticate it either. In the case of SSR/PHP/other means of backend-generation of HTML, yes. I initially limited the PoC to SPAs and deterministic JS bundles. > Also, how do I trust the revelio.json? There's no signature. For now, as I said it's a work in progress, but indeed a way to authenticate the tamper-proof properties of the manifest is necessary. This however brings up the issue of a chain of trust, which is what apparently Tanker is trying to provide with their product. Yet, it raises the question: why should they be trusted ? The commercial viability argument (we don't screw up to stay in business) is not enough IMHO, trust should be based on mathematical proofs, not business rules.