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

Lunar lunar at torproject.org
Sat Jul 27 10:08:32 UTC 2013


Hi,

(Moving the discussion to tor-talk@, as this is not directly related to
the code of Tor software or infrastructure.)

Lag Inimaineb:
> […] 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.
> […]
> First off - there's the technical issue of binding to port 443 locally on
> the web servers without disrupting the currently running local client.
> […]

This technical difficulty could be solved by using something like
sslh [1]: “sslh accepts connections on specified ports, and forwards
them further based on tests performed on the first data packet sent by
the remote client. Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are
implemented, and any other protocol that can be tested using a regular
expression, can be recognised.”

The problem is that if sslh can distinguish protocols that way, so could
DPI boxes. So it would need something a little more convoluted.

[1] http://www.rutschle.net/tech/sslh.shtml

> 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.

More or less. I remember reading about Iran throttling any encrypted
connection that lasted for more than 60 seconds. To a point that made
Tor actually unusable, IIRC.

> 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. :)

Another related idea is called Telex [2]. To sum it up, this is about
diverting seamlessly innocuous traffic at the network level. A censor
could then thus not differentiate from "normal responsesi". One
difference with your idea is that it does not require direct cooperation
from the Internet sites, but with network providers along the path.

I don't know if Telex has ever been deployed in practice.

[2] https://www.usenix.org/event/sec11/tech/full_papers/Wustrow.pdf

-- 
Lunar                                             <lunar at torproject.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20130727/c200d071/attachment.sig>


More information about the tor-talk mailing list