[tor-dev] Idea regarding active probing and follow-up of SSL connections to TOR bridges

[Lag Inimaineb]

Hi,
I've just watched https://www.youtube.com/watch?v=GwMr8Xl7JMQ (old, I
know), and found it very interesting. Also, before going any further, I'd
like to stress that I'm new to tor-dev and while I've googled my question,
I haven't been able to come up with anything, so apologies in advance if
this is already solved.

Anyway, one of the main topics discussed in that talk was the problem of
preventing the blockage of TOR bridges by oppressors. While many "fixes"
were mentioned, none of them actually solve the problem of the bridge being
probed, by following-up on previously captured SSL sessions (as China
does). I was thinking - perhaps instead of making the discovery of the
actual bridge addresses "hard", why not setup bridges in places where other
*legitimate* SSL connections are also made? What I mean is, maybe we should
try and get big sites that cannot be legitimately (in the eyes of the
oppressor, of course) blocked (social media, comic sites, whatever), to run
a TOR bridge *on the same port* as their regular HTTPS traffic (443), in a
way that someone recording the traffic cannot distinguish (in advance, that
is) whether a certain SSL connection to that site is a legitimate web
browsing session, or a TOR session. That way, even if an address on the
internet "speaks" the TOR protocol, it cannot be automatically blocked.
Even if this address is known to host a TOR bridge, this might help
plausible deniability for people unwilling to disclose that they've been
using TOR.

I understand this is probably very difficult, for several reasons, but I
will try to address some of these.

First off - there's the technical issue of binding to port 443 locally on
the web servers without disrupting the currently running local client. I
see several possible ways around this - a simple one could be local
proxying of the SSL connection from the TOR bridge software to the locally
running web server, in a way that when the bridge gets an SSL connection
that isn't "speaking" the TOR protocol, it will be handed over to the web
server. I admit, it's kinda messy, but TBH there are probably more
efficient and "cleaner" ways to do this than what I've suggested.

Also, long running connections with heavy data usage to a web server
address are probably suspicious, but even if these were to be blocked, it
would be on a per-client basis, and would also just mean a QoS issue for
users but not DoS.

Lastly, there's the question of why would a large site agree to this. I
still don't have a good answer for this, but maybe you do... (PR, perhaps?)

Anyway, I'd like to hear what you think. Maybe this isn't an issue anymore,
or maybe you've found a different solution, or mine doesn't work, or you've
already implemented it, etc. :)

laginimaineb.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130706/08c5380e/attachment.html>