3 ms·

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 transi

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.
  - giantrobot 6y ago
    That's where the Signature header comes in. The host can sign the resource and the client can verify the digest and signature. If you're trusting the TLS connection you'd have the same amount of trust in the resource signature.

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.
- giantrobot 6y ago
  That's where the Signature header comes in. The host can sign the resource and the client can verify the digest and signature. If you're trusting the TLS connection you'd have the same amount of trust in the resource signature.