3 ms·

Subresource integrity [1] helps make sure that the javascript referred to by the page is really what gets served. The common usecase talked about is to ensure

Subresource integrity [1] helps make sure that the javascript referred to by the page is really what gets served. The common usecase talked about is to ensure that a compromised CDN can't attack big chunks of the internet. The page itself can still be modified, but there are mitigations that can be performed if you're paranoid enough. 1. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

the8472 10y ago
The threat model I stated included the future compromise of the second party (the hoster). SRI only helps against untrustworthy 3rd parties (CDNs). So it does not really address the issue.
- kybernetikos 10y ago
  Trusting someone to honestly serve you a piece of html is an easier thing to develop and check. You can always save a copy of it to your machine and check it and run it from there. It's true that these are not great against a state level actor deliberately targetting an individual (but then, not much is), but e.g. in a lot of situations I would trust github to serve me unmodified html and s3 to store my encrypted data, where I might have not trusted a single entity to provide me with an integrated solution. It would be great though if a page could indicate that it is sensitive and then if the browser sees it change it pops up a message on the client giving the user a fingerprint and notifying them of the change.
  - yeukhon 10y ago
    If I publish my application on GitHub, how can you know for sure I didn't make changes on the server side? Appearance looks the same m, hence why SRI only solves the front end trust, but the entire as a whole remains a blackbox, thus what previous OP meant.
    - kybernetikos 10y ago
      Depends on the app. If you are making a storage app then you can do client side encryption so that it doesn't matter if s3 is compromised, they don't have access to your data. SRI means you don't have to worry about your js getting modified so all that's left is the html. My claim is that there are lots of situations where I can trust something to serve html honestly enough for my use. It is possible that my bias for web apps that connect to real services (of the sort a desktop app might) rather than as a thin veneer over a black box service gives us a different perspective. But I do ultimately agree that some support for enhancing trust in the initial html document should be built into browsers. I guess such a thing should involve being able to get a hash of the actually downloaded and running code and document and being able to postpone an update until I've had the opportunity to check it's legitimate.
- twiss 10y ago
  I've been thinking about this problem for Airborn OS. In my opinion, the best place to put signatures of the "main resource" would be the website's certificate. [1] I created a Firefox extension that can check signatures both in the certificate and (in the meantime) hardcoded in the extension. [2] [1]: http://blog.airbornos.com/post/2015/04/25/Secure-Delivery-of-JavaScript http://blog.airbornos.com/post/2015/04/25/Secure-Delivery-of... [2]: http://blog.airbornos.com/post/2016/02/23/The-first-web-application-that-doesn-t-trust-the-server http://blog.airbornos.com/post/2016/02/23/The-first-web-appl...
- Klathmon 10y ago
  Well if you trust the website at least once, it can load a service worker which will verify signatures of any app/script updates from any party before allowing them to update the locally cached version of the script.
  - the8472 10y ago
    Service workers can get wiped on hard refreshes or due to space constraints. And they are not easily transferred to new devices, unlike packaged applications. They're not a security mechanism. And it does not necessarily address the compromise of the hoster either, since the attacker who has control over that may also have access to the signing keys. Especially in the case of a court order. That effectively is a silent, user-targetable auto-update of software to which you entrust your secret data. Auto-updates for crypto software should be verifiable through other channels, require user confirmation and use a distribution method that is difficult to scope to a single user to make targeted attacks harder.

the8472 10y ago

The threat model I stated included the future compromise of the second party (the hoster). SRI only helps against untrustworthy 3rd parties (CDNs). So it does not really address the issue.

kybernetikos 10y ago
Trusting someone to honestly serve you a piece of html is an easier thing to develop and check. You can always save a copy of it to your machine and check it and run it from there. It's true that these are not great against a state level actor deliberately targetting an individual (but then, not much is), but e.g. in a lot of situations I would trust github to serve me unmodified html and s3 to store my encrypted data, where I might have not trusted a single entity to provide me with an integrated solution. It would be great though if a page could indicate that it is sensitive and then if the browser sees it change it pops up a message on the client giving the user a fingerprint and notifying them of the change.
- yeukhon 10y ago
  If I publish my application on GitHub, how can you know for sure I didn't make changes on the server side? Appearance looks the same m, hence why SRI only solves the front end trust, but the entire as a whole remains a blackbox, thus what previous OP meant.
  - kybernetikos 10y ago
    Depends on the app. If you are making a storage app then you can do client side encryption so that it doesn't matter if s3 is compromised, they don't have access to your data. SRI means you don't have to worry about your js getting modified so all that's left is the html. My claim is that there are lots of situations where I can trust something to serve html honestly enough for my use. It is possible that my bias for web apps that connect to real services (of the sort a desktop app might) rather than as a thin veneer over a black box service gives us a different perspective. But I do ultimately agree that some support for enhancing trust in the initial html document should be built into browsers. I guess such a thing should involve being able to get a hash of the actually downloaded and running code and document and being able to postpone an update until I've had the opportunity to check it's legitimate.
twiss 10y ago
I've been thinking about this problem for Airborn OS. In my opinion, the best place to put signatures of the "main resource" would be the website's certificate. [1] I created a Firefox extension that can check signatures both in the certificate and (in the meantime) hardcoded in the extension. [2] [1]: http://blog.airbornos.com/post/2015/04/25/Secure-Delivery-of-JavaScript http://blog.airbornos.com/post/2015/04/25/Secure-Delivery-of... [2]: http://blog.airbornos.com/post/2016/02/23/The-first-web-application-that-doesn-t-trust-the-server http://blog.airbornos.com/post/2016/02/23/The-first-web-appl...
Klathmon 10y ago
Well if you trust the website at least once, it can load a service worker which will verify signatures of any app/script updates from any party before allowing them to update the locally cached version of the script.
- the8472 10y ago
  Service workers can get wiped on hard refreshes or due to space constraints. And they are not easily transferred to new devices, unlike packaged applications. They're not a security mechanism. And it does not necessarily address the compromise of the hoster either, since the attacker who has control over that may also have access to the signing keys. Especially in the case of a court order. That effectively is a silent, user-targetable auto-update of software to which you entrust your secret data. Auto-updates for crypto software should be verifiable through other channels, require user confirmation and use a distribution method that is difficult to scope to a single user to make targeted attacks harder.