5 ms·

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

by 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.
- toomuchtodo 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. Can you not trust the originating site to serve non-compromised HTML if using HSTS and a trusted local certificate store (eliminating MITM as an attack vector)?
  - detaro 8y ago
    Not if the originating site is the potential attacker, which was the initial scenario: Protonmail sending you page that leaks your decrypted mail to them.

by 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.
toomuchtodo 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. Can you not trust the originating site to serve non-compromised HTML if using HSTS and a trusted local certificate store (eliminating MITM as an attack vector)?
- detaro 8y ago
  Not if the originating site is the potential attacker, which was the initial scenario: Protonmail sending you page that leaks your decrypted mail to them.