Hey all,
Flashproxy[1] helps to bypass entry-node blocks. But we could apply the general idea to exit-nodes as well - have the exit-node connect to the destination via an ephemeral proxy. The actual technology probably needs to be different since we can't assume the destination has a flashproxy (websocket/webrtc) PT server running, but we could probably find a technical solution to that.
However, I talked this over with a few people and there might be legal and security issues. A few points:
- running an exit node carries a great risk, it would be bad/unethical to let ephemeral proxy runners take this risk - (for security reasons we don't fully understand) there is a process for trusting exit nodes and/or detecting misbehaviour (I see badexit emails from time to time). this would be made much harder if exits were ephemeral. - someone could create a massive number of ephemeral exit nodes and capture a lot of exit traffic, giving them extra data to de-anonymise people.
I was wondering if any of these have been discussed in depth before already, or if the general topic of exit-node block bypassing is something to be explored.
X
[1] http://crypto.stanford.edu/flashproxy
On 2013-12-31 12:07, Ximin Luo wrote:
Hey all,
Flashproxy[1] helps to bypass entry-node blocks. But we could apply the general idea to exit-nodes as well - have the exit-node connect to the destination via an ephemeral proxy.
If an exit node is blocked towards a certain site, that exit node should define a policy stating that it is blocked by that destination. (DirAuths could maybe be made to add extra details like that?)
If an exit node is useless it is a bad exit and should not be used at all, that is, shutdown.
For your 'flashproxy' case, it would just mean 'moving' the exit node to the new exit IP btw. You would thus only be shifting the problem.
Greets, Jeroen
On 31/12/13 12:35, Jeroen Massar wrote:
On 2013-12-31 12:07, Ximin Luo wrote:
Hey all,
Flashproxy[1] helps to bypass entry-node blocks. But we could apply the general idea to exit-nodes as well - have the exit-node connect to the destination via an ephemeral proxy.
If an exit node is blocked towards a certain site, that exit node should define a policy stating that it is blocked by that destination. (DirAuths could maybe be made to add extra details like that?)
If an exit node is useless it is a bad exit and should not be used at all, that is, shutdown.
This is an unrelated topic from my original post. I am asking whether trying to implement an anti-exit-node-blocking-system would be A Good Thing To Do.
For your 'flashproxy' case, it would just mean 'moving' the exit node to the new exit IP btw. You would thus only be shifting the problem.
Those new IPs are ephemeral and unpredictable, therefore not feasible to block. See the flashproxy page on how it works; a few tweaks are needed to make it work for exits, but it's fairly straightforward to do so.
But this is also an unrelated topic. I am less interested in getting it to technically work (because I am convinced it *will* work), but rather on whether it is a good idea or not.
Hey Ximin,
I don't think it's been discussed in-depth before (at least not on-list), but I've thought a fair bit about it. While it's an interesting idea, I don't think that the risks for deploying it far outweigh any minor reward that could come of it. This idea has come up several times in the context of Cupcake "wouldn't it be great if we could" sort of thing. It really wouldn't.
Exit node operators take on some pretty serious legal and security risks if they operate their exit from home. (NEVER DO THIS). More than one person has been raided by police who didn't do their due diligence beforehand. Expanding that into the territory of people who aren't fully aware of their risks would have terrible repercussions.
It also becomes trivial to flood the Tor network with bad ephemeral exits, which disappear before people catch on. Speed would be an issue also.
While I really believe that expanding Flashproxy and Fog and Bridges is extremely important, I don't that's plausible for exit points. Educating groups of website owners about censorship would help us a lot. Circumvention isn't something that's thought a lot about in the US, which unfortunately is where a lot of large websites are based. Unblocking all or portions of [big website] can be extremely helpful to at-risk groups of people, and that's not always obvious to sysops.
~Griffin
Il 31.12.2013 06:07 Ximin Luo ha scritto:
Hey all,
Flashproxy[1] helps to bypass entry-node blocks. But we could apply the general idea to exit-nodes as well - have the exit-node connect to the destination via an ephemeral proxy. The actual technology probably needs to be different since we can't assume the destination has a flashproxy (websocket/webrtc) PT server running, but we could probably find a technical solution to that.
However, I talked this over with a few people and there might be legal and security issues. A few points:
- running an exit node carries a great risk, it would be bad/unethical
to let ephemeral proxy runners take this risk
- (for security reasons we don't fully understand) there is a process
for trusting exit nodes and/or detecting misbehaviour (I see badexit emails from time to time). this would be made much harder if exits were ephemeral.
- someone could create a massive number of ephemeral exit nodes and
capture a lot of exit traffic, giving them extra data to de-anonymise people.
I was wondering if any of these have been discussed in depth before already, or if the general topic of exit-node block bypassing is something to be explored.
X
-
Griffin Boyce -
Jeroen Massar -
Ximin Luo