8 ms·

On a related tangent: In the new secure-by-default world, what happens if a website has some large assets (e.g. video, game files) and would like to opt into c

by comex 12y ago

On a related tangent: In the new secure-by-default world, what happens if a website has some large assets (e.g. video, game files) and would like to opt into caching by any transparent proxies that may be on the user's network? The site could embed hashes of the assets in question, and use ServiceWorker to transparently inject a hash check into any fetches (no matter what HTML thingy initiated them), but I think requests to http: from https: are always blocked as mixed content - let me know if I'm wrong. Also, this would still send things like user-agent, language, any non-secure cookies, etc., and allow the unauthenticated server to set them; it would be good to have a way to opt out of all these things, just sending a minimalist HTTP request instead. Of course, even if these issues are fixed, any system allowing caching of assets must allow tracking of what assets were requested; for some sites this is unlikely to provide much info beyond what the domain name already indicates, but for others it would be best to avoid. On the other hand, if assets have sufficiently distinctive sizes, a proxy might be able to guess this information over HTTPS anyway through simple traffic analysis, so it wouldn't be that harmful to run it over HTTP instead.

JoshTriplett 12y ago
One of these days, I'd like to have a scheme for referencing secure third-party content that includes hashes. I'm never going to link to a third-party server for some JavaScript file that could be changed out from under me, but if I can link to it on a CDN along with a sha256 or similar, and have it grabbed from my own server instead if the hash doesn't match, great! I've seen a few attempts at that, but nothing that has actually taken off. It needs an appropriate polyfill, so that in browsers that don't support it, either the content gets downloaded and hashed client-side, or the content just gets downloaded from the same origin. > In the new secure-by-default world, what happens if a website has some large assets (e.g. video, game files) and would like to opt into caching by any transparent proxies that may be on the user's network? The whole concept of a "transparent" proxy will hopefully die in a secure-only world. If you want some server on your network to MITM your traffic (for caching or any other reason), use a non-transparent proxy. (Or, install a CA certificate from your proxy, but hopefully widespread use of certificate pinning will kill that too.)
- bzbarsky 12y ago
  For what it's worth, http://w3c.github.io/webappsec/specs/subresourceintegrity/ http://w3c.github.io/webappsec/specs/subresourceintegrity/ is actively being worked on, and implementations in Chrome and Firefox are on the way in the near future. The polyfill issue is handled in that proposal as described in <http://w3c.github.io/webappsec/specs/subresourceintegrity/#fallback-1> http://w3c.github.io/webappsec/specs/subresourceintegrity/#f...: Your "src" attribute points to a server you control, but your "noncanonical-src" points to the CDN, and a browser that knows about "noncanonical-src" is also supposed to know about the "integrity" attribute and ensure that the content it gets hashes to what you expect.
  - hrjet 12y ago
    This is very interesting; thanks! I am not very familiar with hashing algorithms, but why isn't the length of the content specified in the `integrity` attribute? Wouldn't it help avoid length extension attacks?
    - JoshTriplett 12y ago
      A good digest alorithm should already handle length extension attacks with just the digest. HMAC algorithms handle that as far as I know, and I think modern hashes don't suffer from the length extension problem in the first place.
      - comex 12y ago
        In any case, length extension attacks apply to (hashes misused as) keyed message authentication codes - a scenario where you give a message and its authenticator to a server knowing the key, and it checks whether someone knowing the key generated them. The attacks let you, given a message and its authenticator, calculate the authenticator for a different message. However, in this case, the hash cannot be tampered with; breaking integrity would require finding a different message with the same hash, which is a straight-up collision, considered to totally break a hash algorithm. At the moment, the only commonly used hash algorithm with known collisions is MD5; SHA-1 will probably follow in the next several years.
mistercow 12y ago
This made me wonder why we don't just have a standard for signing content sent over HTTP. The original server would give the signature to the CDN, which would put the signature in an HTTP header, and then the browser could check that signature against the public key from the main site's SSL cert. Now you know that nobody could have gotten in the middle and sent you a malicious script, and you didn't have to encrypt an innocuous public asset.
jakobegger 12y ago
I'm pretty sure that pages marked a secure shouldn't contain unencrypted content. If people who are on the same wifi network can see what Youtube videos I'm watching, that's hardly a secure connection, is it?

by comex 12y ago

JoshTriplett 12y ago

One of these days, I'd like to have a scheme for referencing secure third-party content that includes hashes. I'm never going to link to a third-party server for some JavaScript file that could be changed out from under me, but if I can link to it on a CDN along with a sha256 or similar, and have it grabbed from my own server instead if the hash doesn't match, great! I've seen a few attempts at that, but nothing that has actually taken off. It needs an appropriate polyfill, so that in browsers that don't support it, either the content gets downloaded and hashed client-side, or the content just gets downloaded from the same origin. > In the new secure-by-default world, what happens if a website has some large assets (e.g. video, game files) and would like to opt into caching by any transparent proxies that may be on the user's network? The whole concept of a "transparent" proxy will hopefully die in a secure-only world. If you want some server on your network to MITM your traffic (for caching or any other reason), use a non-transparent proxy. (Or, install a CA certificate from your proxy, but hopefully widespread use of certificate pinning will kill that too.)

bzbarsky 12y ago
For what it's worth, http://w3c.github.io/webappsec/specs/subresourceintegrity/ http://w3c.github.io/webappsec/specs/subresourceintegrity/ is actively being worked on, and implementations in Chrome and Firefox are on the way in the near future. The polyfill issue is handled in that proposal as described in <http://w3c.github.io/webappsec/specs/subresourceintegrity/#fallback-1> http://w3c.github.io/webappsec/specs/subresourceintegrity/#f...: Your "src" attribute points to a server you control, but your "noncanonical-src" points to the CDN, and a browser that knows about "noncanonical-src" is also supposed to know about the "integrity" attribute and ensure that the content it gets hashes to what you expect.
- hrjet 12y ago
  This is very interesting; thanks! I am not very familiar with hashing algorithms, but why isn't the length of the content specified in the `integrity` attribute? Wouldn't it help avoid length extension attacks?
  - JoshTriplett 12y ago
    A good digest alorithm should already handle length extension attacks with just the digest. HMAC algorithms handle that as far as I know, and I think modern hashes don't suffer from the length extension problem in the first place.
    - comex 12y ago
      In any case, length extension attacks apply to (hashes misused as) keyed message authentication codes - a scenario where you give a message and its authenticator to a server knowing the key, and it checks whether someone knowing the key generated them. The attacks let you, given a message and its authenticator, calculate the authenticator for a different message. However, in this case, the hash cannot be tampered with; breaking integrity would require finding a different message with the same hash, which is a straight-up collision, considered to totally break a hash algorithm. At the moment, the only commonly used hash algorithm with known collisions is MD5; SHA-1 will probably follow in the next several years.

mistercow 12y ago

This made me wonder why we don't just have a standard for signing content sent over HTTP. The original server would give the signature to the CDN, which would put the signature in an HTTP header, and then the browser could check that signature against the public key from the main site's SSL cert. Now you know that nobody could have gotten in the middle and sent you a malicious script, and you didn't have to encrypt an innocuous public asset.

jakobegger 12y ago

I'm pretty sure that pages marked a secure shouldn't contain unencrypted content. If people who are on the same wifi network can see what Youtube videos I'm watching, that's hardly a secure connection, is it?