[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] [tor-dev] Idea regarding active probing and follow-up of SSL connections to TOR bridges
Thanks for the feedback!
Regarding sslh - if I understand correctly, this can be used to
differentiate packets based on the actual payload that was received? If so,
what I meant was that since the TOR protocol is encapsulated within TLS, as
is HTTPS traffic, then the differentiation will have to occur after the TLS
handshake, which (assuming Iran/China/etc do not have a forged
certificate), cannot be viewed by anyone other than the site operator.
However, we could setup sslh after a daemon that performs TLS handshakes,
then run the site and the bridge after that (is that what you meant?).
As for Telex, I've never heard of it before, but I think it's a neat
concept. Maybe something like Telex can be used by the hosting services on
which large sites are hosted (instead of at the ISP level). That might be
more affordable (less TLS handshakes to sift through), and would also be
completely transparent to the site operators (and thus have a higher chance
of actually accepting it).
What do you think? Also, I'd still like to know if this is less of a
problem nowadays (is there a new and better way to distribute TOR bridge
addresses without getting them blocked?)
On Sat, Jul 27, 2013 at 1:08 PM, Lunar <lunar@xxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxx>
>
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk