4 ms·
It needs to happen in-browser because of the modern prevalence of SSL. I think only Firefox has APIs powerful enough to intercept stuff on this level, and even
by _wmd 10y ago
It needs to happen in-browser because of the modern prevalence of SSL. I think only Firefox has APIs powerful enough to intercept stuff on this level, and even those APIs are obsolete, so I think it really needs to be integrated straight into a browser fork. Chrome / Firefox WebExtensions have request interception, but I'm not sure it's powerful enough to do this kind of stuff
(Also, the mere fact such a scheme would have to jinx with the mechanics of a fundamental browser security mechanism should be enough to indicate how difficult it would be to implement safely!)
- j_s 10y agoNot while SSLKeyLogFile is still around. I keep wondering how long it will last, but it's been a while already.
- aianus 10y agoThe cache/proxy just needs to install its root certificate into your system store and no changes to the browser would be necessary.
- _wmd 10y agoIt's not sufficient due to certificate pinning, and it also completely short-circuits any browser-based security policies keyed on the certificate or options advertised in the protocol like SPDY. That would be the worst possible outcome, and why any correct solution (i.e doesn't break security or functionality) would be hard to reach
- detaro 10y agoLocal root certificates are prioritized by all browsers over certificate pinning, for exactly such intentional MITM.
- dredmorbius 10y agoOr an alternate model / protocol for content retrieval. Consider that SSL is largely used for connection encryption, though it has the additional side-effect of site authentication. If you can still validate the site, and rely on a hash of the content to detect changes, then you're starting to get toward a cacheable, secure, autenticated, system. I need to think more about this.