8 ms·

Not that it matters. They could silently replace it with a backdoored script and your browser would never tell you it happened. And to preempt the ProtonMail r

Not that it matters. They could silently replace it with a backdoored script and your browser would never tell you it happened. And to preempt the ProtonMail rep who is probably going to respond to this comment, I know that you can run the web app on localhost. But that doesn't mean that users who don't are any more secure.

bastawhiz 8y ago
The readme indicates that it can be installed via npm, so I'm not sure what your concern is. https://github.com/openpgpjs/openpgpjs/blob/master/README.md https://github.com/openpgpjs/openpgpjs/blob/master/README.md
- Sir_Cmpwn 8y ago
  That doesn't have anything to do with what I said.
  - cdubzzz 8y ago
    To be fair, what you said is only tangentially related to the posted article anyway. It is about a security audit of the OpenPGPjs library (what bastawhiz commented about), not how ProtonMail implements it (what you commented about).
LeoPanthera 8y ago
I don't know if Protonmail do this or not, but presumably you could supply the javascript part of your web application as a browser plugin, which would render it immune to attacks on the server.
taf2 8y ago
isn't this why https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... was invented?
- diggan 8y ago
  If you can change out the JS payload, you can probably also swap out the HTML which supposedly "secures" it. If the users had the option of "locking" a JS version with the Subresource Integrity attribute that they are currently using, it might help.
  - eli 8y ago
    Wouldn't you also need to lock down all the UI code and everything that interacts with the library?
- Sir_Cmpwn 8y ago
  This solves a different problem. Say actor A makes a website and uses CDNs provided by actor B. This protects users from actor B changing their scripts, but not from a malicious actor A. In this case I'm presuming ProtonMail is actor A.
- phaer 8y ago
  No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes. You could however probably provide a signed entry point via a webextension or so and a an audit trail via a trusted distribution plattform, like addons.mozilla.org. Are there apps which use a mechanism like this?
  - jnbiche 8y ago
    There was a way to make a permanent site installation on most browsers using HTML5 appcache, which even the web host couldn't update, but that API is deprecated in favor of the service worker's Cache API. It's not clear to me that the Cache API offers the same level of security guarantee.
    - tlrobinson 8y ago
      > It's not clear to me that the Cache API offers the same level of security guarantee. Last I checked it seemed there wasn’t any way to prevent the service worker itself from being updated.
digianarchist 8y ago
Remember when Hushmail backdoored their client-side applet to capture unencrypted emails and passwords?
- peterwwillis 8y ago
  It appears they were actually just hosting a web app and users were sending their decryption password to Hushmail. I don't see a reference to backdooring the Java client, though obviously since they delivered it, they could do that too. https://www.wired.com/2007/11/encrypted-e-mai/ https://www.wired.com/2007/11/encrypted-e-mai/
- bigiain 8y ago
  I remember when Lavabit didn't...
woranl 8y ago
The same can be said for any software that auto update (i.e. Chrome), no?
- eeZah7Ux 8y ago
  No. The risk is much lower, especially if different entities (upstream, linux distributions, ...) review the same code.
- tlrobinson 8y ago
  That depends. 1. Most platforms these days require a signature with a key issued by the platform. In the browser you have HTTPS but that doesn’t help if the server is compromised. 2. It’s easier to target individuals (thus evading detection) if you’re serving the code to users directly (which I think is also the case with Chrome, but not Mac App Store, Linux package managers, etc) 3. Some platforms even do some amount of auditing before including software in their repositories.
- peterwwillis 8y ago
  Attack vectors for replacing Chrome: - Hack Google Attack vectors for replacing OpenPGPjs: - Hack the servers hosting OpenPGPjs - Hack the browser to inject or replace content across domains, sandboxes, other security barriers It's a subtle difference, but delivering applications dynamically via web browsing is much more precarious than natively hosted applications. Another way to think of it is if your entire Linux OS were actually just web apps with GUIs. Every time you run 'bash', it was actually downloaded from a remote server. And every time you used bash, and it used some plug-in which was hosted on some other site, that plug-in could be compromised, and could be trying to attack your OS, which if successful, would compromise your entire host. That doesn't happen right now because all the apps sit on your host, aren't constantly re-acquired, aren't constantly subject to potential 3rd party attacks over a wide surface area. Though this does sort-of happen with programming language package managers like npm, pip and so on. But you can pin those versions and hashes if you're paranoid, which I don't think you can do with a browser.
  - cortesoft 8y ago
tlrobinson 8y ago
This (rightfully) comes up every time some browser-based encryption tool is posted. It seems like the desire for such tools isn’t going to go away. Is anyone working on solutions for making distribution of JavaScript applications more secure? There’s a range of assurances you could try to provide, e.x. signatures from the author (or even 3rd parties), prompting for updates, etc. It would likely require support from browsers. At one point I investigated using service workers to intercept subsequent app updates to check signatures but there was no way to prevent the service worker itself from being replaced (probably because it would be easy for a site to permanently “brick” itself in users browssr).
- syoc 8y ago
  Have a look at https://w3c.github.io/webappsec-subresource-integrity/ https://w3c.github.io/webappsec-subresource-integrity/
  - tlrobinson 8y ago
    That’s a start, but if the main resource (the HTML page) can be modified it doesn’t help. If you could require the root page be cryptographically signed (but by who?) and optionally prompted for updates then we’re talking.
- pera 8y ago
  A browser add-on that is manually installed (which I believe would stop any potential insecure/unintended automatic update) could check a digital signature embedded in a formatted comment inside the JS file. That is relatively easy to implement, but you will also want some sort of PKI for key distribution and revocation.
  - hahahihi 8y ago
    Let the uri be the signature?
    - dane-pgp 8y ago
eeZah7Ux 8y ago
...not to mention the huge attack surface of browsers in general. And also how the same application you are using to encrypt your mail is also running javascript from random sources when you browse websites.
- eeZah7Ux 8y ago
  ...and why all the downvotes? Interestingly, if I write from other accounts I don't get all this downvoting.
jrruethe 8y ago
These concepts are interesting: https://codegolf.stackexchange.com/questions/18217/javascript-load-and-sha-256 https://codegolf.stackexchange.com/questions/18217/javascrip... https://bitbucket.org/geraintluff/caution.js/ https://bitbucket.org/geraintluff/caution.js/ The idea is that a long data-uri containing hashes and a small loader function are bookmarked. The loader won't load the corresponding javascript unless the hashes match. The user only needs to verify the javascript once, then they can rely on their bookmark containing the hashes. If the server were to swap out the javascript, the bookmark would fail to load it.
- Sir_Cmpwn 8y ago
  Oooh, that's very cool. Thanks for the links.
- SahAssar 8y ago
  Isn't that just SRI in a bookmarklet? With SRI you give the browser a hash and if the resource does not match it does not load.
  - Something1234 8y ago
    Doesn't SRI require the hashes to be in the __loaded__ html? I believe parent is referring to a page which is the same, but has been compromised on the server side, meaning you can't trust the html, even if the server is who it says it is.
    - SahAssar 8y ago
      Right, but what I'm saying is that you don't need the loader. Just have a bookmarklet with html that contains script tags with SRI. The loader is just another step you need to trust.
      - dividuum 8y ago
        That does indeed work. Pretty neat. For anyone trying, here is basically all you need: data:text/html,<script crossorigin="anonymous" integrity="..." src="..."> In total that should be a lot smaller than the linked codegolf answer.
delbel 8y ago
Back in the days when I was 15-16 I added a simple system() call in PGP to send the plaintext message out via sendmail before encrypting it as an experiment on my local system, and was surprised that a one line change would completely compromise the system. I remember telling Phil Zimmerman this at a conference I think he said something like "well, that is a real asshole move". There's nothing to prevent all of these "create secure password checkers" from sending out JSON requests your plaintext password as well. Furthermore, you can send fake "invalid password" messages and trick a user into typing all of his old passwords and permutations while he/she tries to "remember" the right password. One of my first root exploit for OpenBSD was taking over the console, killing login, and presenting a fake login prompt that pipe'd its output to a real one.
zachrose 8y ago
Do either IPFS or DAT/BeakerBrowser solve this problem? (They are both protocols for distributed web apps based on immutable content.)
- sneak 8y ago
  A little, although it involves running your own ipfs node, something precisely 0% (rounded) of web users are going to do.
zaarn 8y ago
How would you implement a secure webmail such that it satisfies your complaint?
Sephr 8y ago
Hopefully web packages⁽¹⁾ can eventually solve this issue. 1. https://github.com/WICG/webpackage https://github.com/WICG/webpackage

bastawhiz 8y ago

The readme indicates that it can be installed via npm, so I'm not sure what your concern is. https://github.com/openpgpjs/openpgpjs/blob/master/README.md https://github.com/openpgpjs/openpgpjs/blob/master/README.md

Sir_Cmpwn 8y ago
That doesn't have anything to do with what I said.
- cdubzzz 8y ago
  To be fair, what you said is only tangentially related to the posted article anyway. It is about a security audit of the OpenPGPjs library (what bastawhiz commented about), not how ProtonMail implements it (what you commented about).

LeoPanthera 8y ago

I don't know if Protonmail do this or not, but presumably you could supply the javascript part of your web application as a browser plugin, which would render it immune to attacks on the server.

taf2 8y ago

isn't this why https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... was invented?

diggan 8y ago
If you can change out the JS payload, you can probably also swap out the HTML which supposedly "secures" it. If the users had the option of "locking" a JS version with the Subresource Integrity attribute that they are currently using, it might help.
- eli 8y ago
  Wouldn't you also need to lock down all the UI code and everything that interacts with the library?
Sir_Cmpwn 8y ago
This solves a different problem. Say actor A makes a website and uses CDNs provided by actor B. This protects users from actor B changing their scripts, but not from a malicious actor A. In this case I'm presuming ProtonMail is actor A.
phaer 8y ago
No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes. You could however probably provide a signed entry point via a webextension or so and a an audit trail via a trusted distribution plattform, like addons.mozilla.org. Are there apps which use a mechanism like this?
- jnbiche 8y ago
  There was a way to make a permanent site installation on most browsers using HTML5 appcache, which even the web host couldn't update, but that API is deprecated in favor of the service worker's Cache API. It's not clear to me that the Cache API offers the same level of security guarantee.
  - tlrobinson 8y ago
    > It's not clear to me that the Cache API offers the same level of security guarantee. Last I checked it seemed there wasn’t any way to prevent the service worker itself from being updated.

digianarchist 8y ago

Remember when Hushmail backdoored their client-side applet to capture unencrypted emails and passwords?

peterwwillis 8y ago
It appears they were actually just hosting a web app and users were sending their decryption password to Hushmail. I don't see a reference to backdooring the Java client, though obviously since they delivered it, they could do that too. https://www.wired.com/2007/11/encrypted-e-mai/ https://www.wired.com/2007/11/encrypted-e-mai/
bigiain 8y ago
I remember when Lavabit didn't...

woranl 8y ago

The same can be said for any software that auto update (i.e. Chrome), no?

eeZah7Ux 8y ago
No. The risk is much lower, especially if different entities (upstream, linux distributions, ...) review the same code.
tlrobinson 8y ago
That depends. 1. Most platforms these days require a signature with a key issued by the platform. In the browser you have HTTPS but that doesn’t help if the server is compromised. 2. It’s easier to target individuals (thus evading detection) if you’re serving the code to users directly (which I think is also the case with Chrome, but not Mac App Store, Linux package managers, etc) 3. Some platforms even do some amount of auditing before including software in their repositories.
peterwwillis 8y ago
Attack vectors for replacing Chrome: - Hack Google Attack vectors for replacing OpenPGPjs: - Hack the servers hosting OpenPGPjs - Hack the browser to inject or replace content across domains, sandboxes, other security barriers It's a subtle difference, but delivering applications dynamically via web browsing is much more precarious than natively hosted applications. Another way to think of it is if your entire Linux OS were actually just web apps with GUIs. Every time you run 'bash', it was actually downloaded from a remote server. And every time you used bash, and it used some plug-in which was hosted on some other site, that plug-in could be compromised, and could be trying to attack your OS, which if successful, would compromise your entire host. That doesn't happen right now because all the apps sit on your host, aren't constantly re-acquired, aren't constantly subject to potential 3rd party attacks over a wide surface area. Though this does sort-of happen with programming language package managers like npm, pip and so on. But you can pin those versions and hashes if you're paranoid, which I don't think you can do with a browser.
- cortesoft 8y ago

tlrobinson 8y ago

This (rightfully) comes up every time some browser-based encryption tool is posted. It seems like the desire for such tools isn’t going to go away. Is anyone working on solutions for making distribution of JavaScript applications more secure? There’s a range of assurances you could try to provide, e.x. signatures from the author (or even 3rd parties), prompting for updates, etc. It would likely require support from browsers. At one point I investigated using service workers to intercept subsequent app updates to check signatures but there was no way to prevent the service worker itself from being replaced (probably because it would be easy for a site to permanently “brick” itself in users browssr).

syoc 8y ago
Have a look at https://w3c.github.io/webappsec-subresource-integrity/ https://w3c.github.io/webappsec-subresource-integrity/
- tlrobinson 8y ago
  That’s a start, but if the main resource (the HTML page) can be modified it doesn’t help. If you could require the root page be cryptographically signed (but by who?) and optionally prompted for updates then we’re talking.
pera 8y ago
A browser add-on that is manually installed (which I believe would stop any potential insecure/unintended automatic update) could check a digital signature embedded in a formatted comment inside the JS file. That is relatively easy to implement, but you will also want some sort of PKI for key distribution and revocation.
- hahahihi 8y ago
  Let the uri be the signature?
  - dane-pgp 8y ago

eeZah7Ux 8y ago

...not to mention the huge attack surface of browsers in general. And also how the same application you are using to encrypt your mail is also running javascript from random sources when you browse websites.

eeZah7Ux 8y ago
...and why all the downvotes? Interestingly, if I write from other accounts I don't get all this downvoting.

jrruethe 8y ago

These concepts are interesting: https://codegolf.stackexchange.com/questions/18217/javascript-load-and-sha-256 https://codegolf.stackexchange.com/questions/18217/javascrip... https://bitbucket.org/geraintluff/caution.js/ https://bitbucket.org/geraintluff/caution.js/ The idea is that a long data-uri containing hashes and a small loader function are bookmarked. The loader won't load the corresponding javascript unless the hashes match. The user only needs to verify the javascript once, then they can rely on their bookmark containing the hashes. If the server were to swap out the javascript, the bookmark would fail to load it.

Sir_Cmpwn 8y ago
Oooh, that's very cool. Thanks for the links.
SahAssar 8y ago
Isn't that just SRI in a bookmarklet? With SRI you give the browser a hash and if the resource does not match it does not load.
- Something1234 8y ago
  Doesn't SRI require the hashes to be in the __loaded__ html? I believe parent is referring to a page which is the same, but has been compromised on the server side, meaning you can't trust the html, even if the server is who it says it is.
  - SahAssar 8y ago
    Right, but what I'm saying is that you don't need the loader. Just have a bookmarklet with html that contains script tags with SRI. The loader is just another step you need to trust.
    - dividuum 8y ago
      That does indeed work. Pretty neat. For anyone trying, here is basically all you need: data:text/html,<script crossorigin="anonymous" integrity="..." src="..."> In total that should be a lot smaller than the linked codegolf answer.

delbel 8y ago

Back in the days when I was 15-16 I added a simple system() call in PGP to send the plaintext message out via sendmail before encrypting it as an experiment on my local system, and was surprised that a one line change would completely compromise the system. I remember telling Phil Zimmerman this at a conference I think he said something like "well, that is a real asshole move". There's nothing to prevent all of these "create secure password checkers" from sending out JSON requests your plaintext password as well. Furthermore, you can send fake "invalid password" messages and trick a user into typing all of his old passwords and permutations while he/she tries to "remember" the right password. One of my first root exploit for OpenBSD was taking over the console, killing login, and presenting a fake login prompt that pipe'd its output to a real one.

zachrose 8y ago

Do either IPFS or DAT/BeakerBrowser solve this problem? (They are both protocols for distributed web apps based on immutable content.)

sneak 8y ago
A little, although it involves running your own ipfs node, something precisely 0% (rounded) of web users are going to do.

zaarn 8y ago

How would you implement a secure webmail such that it satisfies your complaint?

Sephr 8y ago

Hopefully web packages⁽¹⁾ can eventually solve this issue. 1. https://github.com/WICG/webpackage https://github.com/WICG/webpackage