3 ms·
Next can we apply it to whole HTML documents (including iFrames)? Then malicious ISPs/malware/etc would be unable to inject their ad spam code.
by ihsw 11y ago
Next can we apply it to whole HTML documents (including iFrames)? Then malicious ISPs/malware/etc would be unable to inject their ad spam code.
- deathanatos 11y agoFor the main HTML document, what would prevent the ISP from simply changing the hash to include/account for the injected ad spam code?[1] (for iframes, I think this would work fine) [1]: I'm presuming you're not using TLS, because if you were, then TLS would do this and more.
- ihsw 11y agoNot a whole lot, TBH. It raises the bar though from blind injection, which I think is quite good.
- matt_heimer 11y agoThis works because you trust the HTML provider (as a source of a valid hash) but not the CDN. If you don't trust your ISP then getting trusted hashes becomes more interesting. You'd need an encrypted/unmodifiable connection to a 3rd party repository of hashes for HTTP content but that'd only work for shared identical content (like the stuff in a CDN). For personalized content (any website with a login) you need a personalized hash, an HTTPS response could have a header with a hash (RFC 3230: Instance Digests in HTTP) but you can only trust that if you trust HTTPS and if you trust HTTPS then what does the header really add? You probably need two ISPs or at least VPNs if you want to start detecting tampering by an ISP.
- ihsw 11y agoThe idea is to provide protection even in HTTP-only environments (as HTTP is enforced in some places). It would add overhead to verify hashes in the manner that you have mentioned but I think it's worth it.
- codedokode 11y agoYou can just use HTTPS for that.