5 ms·

> If you take a look at the javascript How do I automatically validate that the JS hasn't changed between visits on my mobile? (This is the problem with zero-

> If you take a look at the javascript How do I automatically validate that the JS hasn't changed between visits on my mobile? (This is the problem with zero-knowledge-via-JS-delivery platforms that I've been unable to solve to date)

mikepurvis 6y ago
I believe the current direction is to piggy-back off of subresource integrity: https://w3c.github.io/webappsec-subresource-integrity/ https://w3c.github.io/webappsec-subresource-integrity/ As written, it's more about a page validating the asset from a CDN, but it wouldn't be hard to also have a browser extension which pops up an SSL-like badge when all script resources on a page are marked as trusted by some validating third party.
TimTheTinker 6y ago
This is also the weak link in client web apps for security products like 1Password, where the weakest link is the integrity of the static files loaded by the browser. Break into their static file server or CDN/edge cache and you've effectively pwned any browser sessions started after that point. (This also applies to builds of client software, but for most operating systems those builds have to be signed with a private key, which makes them more difficult to compromise. On Linux, SHA256 checksums are usually provided alongside binaries - which are especially important to use against security-related client software.)
- giantrobot 6y ago
  Browsers support Subresource Integrity [0] checks. You provide an integrity attribute (or several) for a script or link resource and the browser will check the hash(es) before using the resource. [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... [1] https://w3c-test.org/subresource-integrity/subresource-integrity.html https://w3c-test.org/subresource-integrity/subresource-integ...
  - fabrice_d 6y ago
    Yes, but there is the problem of bootstrapping that chain of trust: how do you know that the SRI attribute value has not been tampered with? TLS protects transit, but not server side breaches.
    - TimTheTinker 6y ago
      Right. Subresource integrity checks eliminate the need to trust the source of the subresource, but not the main resource (the HTML response that bootstraps the app). But I'm willing to bet 1Password and the like never trusted third parties to host <link> and <script> assets anyway.
    - giantrobot 6y ago
      If you're doing an SPA where the HTML is just loading your JavaScript for the meat of your app it's straightforward to verify that file. Besides literally comparing its hash to a known good value there's the Digest header [0] which is a way to provide a resource hash to a client. From the browser side there's the Want-Digest header [1]. These replaced the Content-MD5 header. While browsers support these headers I don't think any currently reject a page or resource if a digest doesn't match. But at least the mechanism is there. There's also the draft [2] for signed HTTP messages. So a response can be signed and verified against a public key. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Di... [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Wa... [2] https://tools.ietf.org/id/draft-cavage-http-signatures-10.html https://tools.ietf.org/id/draft-cavage-http-signatures-10.ht...
      - TimTheTinker 6y ago
        If I understand correctly the digest is only to make sure it didn't change while in transit. If the file itself that's being served was compromised, the web server will serve it with a new digest that matches.
        6y ago

mikepurvis 6y ago

I believe the current direction is to piggy-back off of subresource integrity: https://w3c.github.io/webappsec-subresource-integrity/ https://w3c.github.io/webappsec-subresource-integrity/ As written, it's more about a page validating the asset from a CDN, but it wouldn't be hard to also have a browser extension which pops up an SSL-like badge when all script resources on a page are marked as trusted by some validating third party.

TimTheTinker 6y ago

This is also the weak link in client web apps for security products like 1Password, where the weakest link is the integrity of the static files loaded by the browser. Break into their static file server or CDN/edge cache and you've effectively pwned any browser sessions started after that point. (This also applies to builds of client software, but for most operating systems those builds have to be signed with a private key, which makes them more difficult to compromise. On Linux, SHA256 checksums are usually provided alongside binaries - which are especially important to use against security-related client software.)

giantrobot 6y ago
Browsers support Subresource Integrity [0] checks. You provide an integrity attribute (or several) for a script or link resource and the browser will check the hash(es) before using the resource. [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... [1] https://w3c-test.org/subresource-integrity/subresource-integrity.html https://w3c-test.org/subresource-integrity/subresource-integ...
- fabrice_d 6y ago
  Yes, but there is the problem of bootstrapping that chain of trust: how do you know that the SRI attribute value has not been tampered with? TLS protects transit, but not server side breaches.
  - TimTheTinker 6y ago
    Right. Subresource integrity checks eliminate the need to trust the source of the subresource, but not the main resource (the HTML response that bootstraps the app). But I'm willing to bet 1Password and the like never trusted third parties to host <link> and <script> assets anyway.
  - giantrobot 6y ago
    If you're doing an SPA where the HTML is just loading your JavaScript for the meat of your app it's straightforward to verify that file. Besides literally comparing its hash to a known good value there's the Digest header [0] which is a way to provide a resource hash to a client. From the browser side there's the Want-Digest header [1]. These replaced the Content-MD5 header. While browsers support these headers I don't think any currently reject a page or resource if a digest doesn't match. But at least the mechanism is there. There's also the draft [2] for signed HTTP messages. So a response can be signed and verified against a public key. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Di... [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Want-Digest https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Wa... [2] https://tools.ietf.org/id/draft-cavage-http-signatures-10.html https://tools.ietf.org/id/draft-cavage-http-signatures-10.ht...
    - TimTheTinker 6y ago
      If I understand correctly the digest is only to make sure it didn't change while in transit. If the file itself that's being served was compromised, the web server will serve it with a new digest that matches.
      - 6y ago