11–20 of 100 posts
Tanker is an open-source client SDK that can be embedded in any application. Encrypt data, share it between users, create groups, etc. The SDK handles key exchanges, cryptographic operations, and identity verification for you. Also available for iOS and Android!
The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
> 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…
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.
The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Ed: it might, for example be easier to email an attached minimal html file, than a 50mb electron app (multiply by 5 for working on the five major platforms; windows, Linux, Macos, Android and ios). That email might be internal, or signed however you usually sign mails (gpg, s/mime). Or you could host it on a minimal, secure webserver that only served static files over ssl etc
The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
There are risks, and there are procedures for mitigating risk. If you're building an app for privacy and security, you are going to take the appropriate measures, and let your users knows how to use. For instance, you are not going to load some random 3rd party adware into the app, obvi.
At the end of the day, people have to combine a care for their security with available best practices, and then move on with life. People can't thrive in the either/or of infosec's paranoid-hermit mentality (and tech's "people can't understand" paternalism).
Tanker is an open-source client SDK that can be embedded in any application. Encrypt data, share it between users, create groups, etc. The SDK handles key exchanges, cryptographic operations, and identity verification for you. Also available for iOS and Android!
What algorithms? Pretty bare README for a cryptography project.
The canonical example that doesn't make sense is when Alice and Bob want to communicate privately using Eve as a webmail/chat provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of E2Ejs in a tag on EveMail.com, because then they're trusting Eve to provide a legitimate encryption implementation, trusting Eve not to log their keystrokes in JS, etc.
I can understand E2E js as a server-side library in Node (though I suspect it would be safer to run a battle-hardened library like GPG with node FFI).
But, in client-side web code, how could this ever make sense?
The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
How is it any less trustworthy than a native app? It's perfectly possible to fingerprint any JavaScript that gets loaded.
I keep asking, what is the threat model for end-to-end encryption in JS? Like, is there an Alice, Bob, Carol, Eve story under which E2E in JS makes sense? The canonical example that doesn't make sense is when Alice and Bob want to communicate privately using Eve as a webmail/chat provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of E2Ejs in a tag on EveMail.com…
Or you can follow the mega model where the hoster wants to protect itself from legal demands of monitoring user uploads that stop short of demanding encryption backdoors.
It is a fairly weak and narrow security model. Nothing that should be used if you need serious security against powerful attackers.
Earlier quoted context omitted.
> 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…
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.
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.
The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
Subresource integrity can help a bit. You still need to bootstrap from a trusted source though (eg a minimal index.html stored locally). And at that point, you really are back to figuring out a way to distribute a "known good" piece of software. https://developer.mozilla.org/en-US/docs/Web/Security/Subres... Ed: it might, for example be easier to email an attached minimal html file, than a 50mb electron app (multiply…