Jacob Hoffman-Andrews <[email protected]> writes: Martin emailed me separately, specifically about heproxy. My thoughts inline (which I hope gives Martin the info from me that he's looking for :) )!
> My main concerns are: > - How do you make sure you get updates? > - How do you deal with changed ruleset semantics? One of the reasons my project heproxy stalled was due to the hackiness of having to track changes to rulesets, and changes when refactorings occur to the format (which I think this has been done recently -- but haven't been following closely(?)). It's also the case that they *may* be incomplete. This isn't something that's easily addressable without, say, spidering the internet looking for secure equivalents to non-secure endpoints. I *guess* that could be possible, but as the HTTPSEverywhere rulesets have encoded, it's a very tricky problem full of rewriting of lots of different parts of URLs, not just a hostname and URL protocol. > You'll probably need some special logic around cookies. What happens > when a site sets a cookie with the secure flag? If you pass that to the > browser, and the browser thinks it is talking HTTP, it won't send the > cookie on subsequent requests. Ooooh! This is an interesting bug in heproxy which I actually hadn't encountered, but probably would have if I had continued using / developing it. I wanna say it'd be as simple as snarfing cookies and modifying them. But, you can't really be too sure how the user is connecting. Unsetting the secure flag via the proxy so it'll always be sent back, could be horrific if you happen to not be talking through the proxy, and not via TLS, somewhere else... > You'll also want to think carefully about what happens as users migrate > on and off of your network. I.e. they may have a set of sites open to > their HTTP version, but while they were behind your proxy they were > getting automatically rewritten to HTTPS for the rest of their trip. Is > it okay for users to start leaking cookies over HTTP with no warning if > they migrate off your network? Another excellent point! This is an interesting concern which heproxy originally addressed by being "lightweight" enough to just run locally. That doesn't help everyone on the network, of course, but wasn't my goal. Because the network is layered, I think it makes sense to utilize an HE privoxy like proxy as a *fallback* on the network. Each endpoint on the network is responsible for ensuring that their traffic is encrypted (maybe by installing HE in their browser), but the proxy is an additional layer of protection for those cases when a browser isn't in use (e.g. an application phoning home, but other wise respects proxy settings -- [would this happen in real life? lol]), or those guests that don't have endpoint protection at the top of their priority. > It would help to know some more about your planned deployment scenario. > How big a network? Wireless or wired? How much control over the endpoints? > > I think in many cases it might be more effective to strongly encourage > your users to install the HTTPS Everywhere extension. HTTPS Everywhere doesn't really give you HTTPS *Everywhere*, except in the browsers that it supports. You might say, well, just use a supported browser, but this might not be the preference of all people on a network. But, again, see my point above about fallback. I still think the idea is worthy for that purpose alone. Cheers!
signature.asc
Description: PGP signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
