5 ms·

The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-

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 trust audits and if any 3rd-party code is loaded into the environment you can't trust the entire origin. The browser is the wrong tool for the job here.

msy_ 7y ago
Could it be done with a browser extension?
- CiPHPerCoder 7y ago
  You'd think, but everyone I know that explored this option ended up just implementing desktop software instead (e.g. with Electron).
  - tptacek 7y ago
    Part of that is because by the time you're asking an ordinary user (not a super-opinionated "sophisticate" on HN) to install a Chrome extension, you're 95% of the way towards getting them to install a desktop application anyways, and that remaining 5% of effort is often worth the extra flexibility the Electron app gets you.
- pjc50 7y ago
  You need the opposite of an extension, because in-browser crypto is incompatible with having any other "untrusted" extension. What you need is something with a reduced but secure feature set.
- michaelchisari 7y ago
  Ideally, it would be something the browser supported internally (without external js or plugins) with very minimal javascript entrypoints to decode/encode.
- _rlx_ 7y ago
  This is what the webext-signed-pages [1] extension does. This only works in a secure manner with Firefox though because Chrome extensions don't have access to the content of the HTTP responses [2]. [1] https://github.com/tasn/webext-signed-pages https://github.com/tasn/webext-signed-pages [2] https://bugs.chromium.org/p/chromium/issues/detail?id=487422 https://bugs.chromium.org/p/chromium/issues/detail?id=487422
jakelazaroff 7y ago
How is it any less trustworthy than a native app? It's perfectly possible to fingerprint any JavaScript that gets loaded.
- the8472 7y ago
  In theory it's possible, sure. But in practice webapps are not set up for reproducible, auditable, signed builds with zero dynamic execution of 3rd-party code and making those signatures available in a standarized format. Plus browsers lack the tools to make this kind of fingerprinting effortless to verify for the user.
  - jakelazaroff 7y ago
    Sure, but how often do users do this in practice for any apps? I know I don't check the fingerprints for Signal or WhatsApp or iMessage on my phone. And even if the actual binary I'm running is secure, plenty of apps that claim to provide E2E encryption don't give me any way to verify the key of the other user. How do I know that iMessage or Facebook Messenger aren't inserting their own key pairs me and the people I'm messaging?
franky47 7y ago
> 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.
jopsen 7y ago
Right now, sure. That doesn't mean there are reasons to do client side crypto in the browser. Finally, who is to say the web won't get TOFU someday. I'm not even sure you can't do it today using service-workers.
e12e 7y ago
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/Subresource_Integrity 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
- cdata 7y ago
  A known good entry point could be delivered over a content-addressed medium like IPFS, and if you layer on SXG the consumer might still be able to validate the origin of the entry point. https://docs.ipfs.io/guides/concepts/ https://docs.ipfs.io/guides/concepts/ https://github.com/ipfs/in-web-browsers/issues/121 https://github.com/ipfs/in-web-browsers/issues/121
- the8472 7y ago
  You would still have to combine SRI with a fairly strong CSP to avoid any code execution except SRI-covered stuff. It would be a good PoC I guess, but not practical yet for most people.
  - e12e 7y ago
    We're talking about a html file that's basically: <html> <script src=example.cdn/app.js (SRI hash) /> </html> If your app.js go including unknown fonts and js etc... Then, yeah, you've got problems.
  - AgentME 7y ago
    CSP would only be necessary if the SRI-covered stuff had bugs that let it accidentally load unverified resources. (To be clear, I think CSP is a necessary defense-in-depth measure for everyone, but this case doesn't uniquely require it.)
angel_j 7y ago
This is FUD. That's nothing you can't say about all info security practice. Fingerprints and certs you say? Been done since forever, it's called SSL and SHA-2. 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).
panarky 7y ago
Innovator - To help me ride my bike on dangerous mountain trails, I made a sturdy frame and fat, knobby tires. HN - The bike is the wrong tool for transportation in mountains. For absolute safety you must only use a cable car or funicular. Innovator - But cable cars and funiculars are impractical for the mountain trails I want to ride, and my current road race bike with weak frame and skinny tires is dangerous off-road. HN - A sturdy frame and fat, knobby tires only provide the illusion of safety, which is worse than no safety at all. Never go to the mountains unless you're in a cable car or funicular.
- eljimmy 7y ago
  Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks.
  - penagwin 7y ago
    cough it doesn't really matter cough Innovator - To help communicate with other HN readers, I created an analogy about mountain bikes and their tire size! HN - Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks. Innovator - My analogy still makes sense though? Consider my physical safety to be roughly equivalent to information security. While bike locks could certainly work for the analogy as well they just weren't the choice we decided to go with. HN - Your analogy falls apart with edge cases X, Y and Z', bike locks have been used for analogies since.....
    - osrec 7y ago
      Reminds me of a recent discussion I had on HN! https://news.ycombinator.com/item?id=19873055 https://news.ycombinator.com/item?id=19873055 This particular response really made me chuckle: https://news.ycombinator.com/item?id=19873801 https://news.ycombinator.com/item?id=19873801 My analogy related to SQL, but we ended up talking about the complexities of physics...
    - kevin_thibedeau 7y ago
_rlx_ 7y ago
> Without fingerprinting/certification of the entire javascript-source the server > could serve a manipulated source code that exfiltrates data This is actually one of the described use cases of the new webpackage specification: https://tools.ietf.org/html/draft-yasskin-webpackage-use-cases-01#section-2.2.3 https://tools.ietf.org/html/draft-yasskin-webpackage-use-cas... Here is the current draft: https://wicg.github.io/webpackage/draft-yasskin-dispatch-web-packaging.html https://wicg.github.io/webpackage/draft-yasskin-dispatch-web...

msy_ 7y ago

Could it be done with a browser extension?

CiPHPerCoder 7y ago
You'd think, but everyone I know that explored this option ended up just implementing desktop software instead (e.g. with Electron).
- tptacek 7y ago
  Part of that is because by the time you're asking an ordinary user (not a super-opinionated "sophisticate" on HN) to install a Chrome extension, you're 95% of the way towards getting them to install a desktop application anyways, and that remaining 5% of effort is often worth the extra flexibility the Electron app gets you.
pjc50 7y ago
You need the opposite of an extension, because in-browser crypto is incompatible with having any other "untrusted" extension. What you need is something with a reduced but secure feature set.
michaelchisari 7y ago
Ideally, it would be something the browser supported internally (without external js or plugins) with very minimal javascript entrypoints to decode/encode.
_rlx_ 7y ago
This is what the webext-signed-pages [1] extension does. This only works in a secure manner with Firefox though because Chrome extensions don't have access to the content of the HTTP responses [2]. [1] https://github.com/tasn/webext-signed-pages https://github.com/tasn/webext-signed-pages [2] https://bugs.chromium.org/p/chromium/issues/detail?id=487422 https://bugs.chromium.org/p/chromium/issues/detail?id=487422

jakelazaroff 7y ago

How is it any less trustworthy than a native app? It's perfectly possible to fingerprint any JavaScript that gets loaded.

the8472 7y ago
In theory it's possible, sure. But in practice webapps are not set up for reproducible, auditable, signed builds with zero dynamic execution of 3rd-party code and making those signatures available in a standarized format. Plus browsers lack the tools to make this kind of fingerprinting effortless to verify for the user.
- jakelazaroff 7y ago
  Sure, but how often do users do this in practice for any apps? I know I don't check the fingerprints for Signal or WhatsApp or iMessage on my phone. And even if the actual binary I'm running is secure, plenty of apps that claim to provide E2E encryption don't give me any way to verify the key of the other user. How do I know that iMessage or Facebook Messenger aren't inserting their own key pairs me and the people I'm messaging?

franky47 7y ago

> 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.

jopsen 7y ago

Right now, sure. That doesn't mean there are reasons to do client side crypto in the browser. Finally, who is to say the web won't get TOFU someday. I'm not even sure you can't do it today using service-workers.

e12e 7y ago

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/Subresource_Integrity 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

cdata 7y ago
A known good entry point could be delivered over a content-addressed medium like IPFS, and if you layer on SXG the consumer might still be able to validate the origin of the entry point. https://docs.ipfs.io/guides/concepts/ https://docs.ipfs.io/guides/concepts/ https://github.com/ipfs/in-web-browsers/issues/121 https://github.com/ipfs/in-web-browsers/issues/121
the8472 7y ago
You would still have to combine SRI with a fairly strong CSP to avoid any code execution except SRI-covered stuff. It would be a good PoC I guess, but not practical yet for most people.
- e12e 7y ago
  We're talking about a html file that's basically: <html> <script src=example.cdn/app.js (SRI hash) /> </html> If your app.js go including unknown fonts and js etc... Then, yeah, you've got problems.
- AgentME 7y ago
  CSP would only be necessary if the SRI-covered stuff had bugs that let it accidentally load unverified resources. (To be clear, I think CSP is a necessary defense-in-depth measure for everyone, but this case doesn't uniquely require it.)

angel_j 7y ago

This is FUD. That's nothing you can't say about all info security practice. Fingerprints and certs you say? Been done since forever, it's called SSL and SHA-2. 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).

panarky 7y ago

Innovator - To help me ride my bike on dangerous mountain trails, I made a sturdy frame and fat, knobby tires. HN - The bike is the wrong tool for transportation in mountains. For absolute safety you must only use a cable car or funicular. Innovator - But cable cars and funiculars are impractical for the mountain trails I want to ride, and my current road race bike with weak frame and skinny tires is dangerous off-road. HN - A sturdy frame and fat, knobby tires only provide the illusion of safety, which is worse than no safety at all. Never go to the mountains unless you're in a cable car or funicular.

eljimmy 7y ago
Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks.
- penagwin 7y ago
  cough it doesn't really matter cough Innovator - To help communicate with other HN readers, I created an analogy about mountain bikes and their tire size! HN - Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks. Innovator - My analogy still makes sense though? Consider my physical safety to be roughly equivalent to information security. While bike locks could certainly work for the analogy as well they just weren't the choice we decided to go with. HN - Your analogy falls apart with edge cases X, Y and Z', bike locks have been used for analogies since.....
  - osrec 7y ago
    Reminds me of a recent discussion I had on HN! https://news.ycombinator.com/item?id=19873055 https://news.ycombinator.com/item?id=19873055 This particular response really made me chuckle: https://news.ycombinator.com/item?id=19873801 https://news.ycombinator.com/item?id=19873801 My analogy related to SQL, but we ended up talking about the complexities of physics...
  - kevin_thibedeau 7y ago

_rlx_ 7y ago

> Without fingerprinting/certification of the entire javascript-source the server > could serve a manipulated source code that exfiltrates data This is actually one of the described use cases of the new webpackage specification: https://tools.ietf.org/html/draft-yasskin-webpackage-use-cases-01#section-2.2.3 https://tools.ietf.org/html/draft-yasskin-webpackage-use-cas... Here is the current draft: https://wicg.github.io/webpackage/draft-yasskin-dispatch-web-packaging.html https://wicg.github.io/webpackage/draft-yasskin-dispatch-web...