[HTTPS-Everywhere] Using the rules in a proxy?

[Andrew Gwozdziewycz]

Jacob Hoffman-Andrews <jsha at eff.org> 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!



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20150708/46bd57e3/attachment-0001.sig>