4 ms·

There's one component of the web that everybody seem to forget : the proxy. HTTPS breaks proxies and breaks caching. Which is a crucial part of the architectur

by slim 10y ago

There's one component of the web that everybody seem to forget : the proxy. HTTPS breaks proxies and breaks caching. Which is a crucial part of the architecture of the web. And that's a huge issue especially for developing countries. Bandwidth is costly and the way telcos exchange does not help. Most of our activity on the web is public as in a public space. That's fine and maybe even actually good. There is no need to scare people from HTTP, we should educate people on how to use public spaces on the internet

zeveb 10y ago
> There's one component of the web that everybody seem to forget : the proxy. > HTTPS breaks proxies and breaks caching. I wonder if RFC 2660 S-HTTP[1] would have helped here. > Most of our activity on the web is public as in a public space. That's fine and maybe even actually good. I think what we've discovered is that this isn't actually true: many things do need to be secret, and in order for things to be secret those things need to hide in a cloud of things which don't really matter. [1] https://tools.ietf.org/html/rfc2660 https://tools.ietf.org/html/rfc2660
- slim 10y ago
  Secret from whom? Most of the information we're talking about is shared among CDNs and Ad networks. It just gives a false sense of privacy to consider this kind of information private
- slim 10y ago
  S-HTTP looks awesome. I did no know about it. Thanks
AgentME 10y ago
HTTPS not only protects against eavesdroppers: it also protects against from people manipulating the connection and replacing content (like swapping exe downloads for infected executables). If untrusted caching-proxies are important, then there should be a new caching-proxy-compatible protocol which carries signed data without encrypting it, and browsers should communicate when it's in use.
- slim 10y ago
  Subresource Integrity is better suited for that use case http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
  - deleted 10y ago
    [deleted]
  - xtian 10y ago
    SRI is meaningless on an insecure page.
    - paulddraper 10y ago
      But it isn't meaningless for the assets in a secure page. Those are usually the things you want to cache anyway.
  - AgentME 10y ago
    Subresource integrity isn't supposed to be a replacement for HTTPS. SRI is useful when you're relying on content from another domain, like loading jquery from a CDN that you're not sure is trustworthy. Just because the CDN may support HTTPS doesn't mean that you trust the CDN to give an unbackdoored version of jquery. SRI is used to require that the copy of jquery they give matches a specific hash. HTTPS can still be useful with SRI for privacy. SRI doesn't protect or verify the downloads of html pages generally.
paulddraper 10y ago
You can still use a proxy. You just have to trust its cert and let it MITM you. You always had to trust the proxy; this just makes the trust explicit.

by slim 10y ago

zeveb 10y ago

> There's one component of the web that everybody seem to forget : the proxy. > HTTPS breaks proxies and breaks caching. I wonder if RFC 2660 S-HTTP[1] would have helped here. > Most of our activity on the web is public as in a public space. That's fine and maybe even actually good. I think what we've discovered is that this isn't actually true: many things do need to be secret, and in order for things to be secret those things need to hide in a cloud of things which don't really matter. [1] https://tools.ietf.org/html/rfc2660 https://tools.ietf.org/html/rfc2660

slim 10y ago
Secret from whom? Most of the information we're talking about is shared among CDNs and Ad networks. It just gives a false sense of privacy to consider this kind of information private
slim 10y ago
S-HTTP looks awesome. I did no know about it. Thanks

AgentME 10y ago

HTTPS not only protects against eavesdroppers: it also protects against from people manipulating the connection and replacing content (like swapping exe downloads for infected executables). If untrusted caching-proxies are important, then there should be a new caching-proxy-compatible protocol which carries signed data without encrypting it, and browsers should communicate when it's in use.

slim 10y ago
Subresource Integrity is better suited for that use case http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- deleted 10y ago
  [deleted]
- xtian 10y ago
  SRI is meaningless on an insecure page.
  - paulddraper 10y ago
    But it isn't meaningless for the assets in a secure page. Those are usually the things you want to cache anyway.
- AgentME 10y ago
  Subresource integrity isn't supposed to be a replacement for HTTPS. SRI is useful when you're relying on content from another domain, like loading jquery from a CDN that you're not sure is trustworthy. Just because the CDN may support HTTPS doesn't mean that you trust the CDN to give an unbackdoored version of jquery. SRI is used to require that the copy of jquery they give matches a specific hash. HTTPS can still be useful with SRI for privacy. SRI doesn't protect or verify the downloads of html pages generally.

paulddraper 10y ago

You can still use a proxy. You just have to trust its cert and let it MITM you. You always had to trust the proxy; this just makes the trust explicit.