Hack up stunnel to test a transport that uses a vanilla SSL handshake

Starting a week or two back, we've been getting reports that Tor in Iran is suddenly much slower: https://blog.torproject.org/blog/iran-blocks-tor-tor-releases-same-day-fix#comment-12115

It's not clear whether the slowness comes from the Tor network or from some external factor. But it's reasonable to imagine that one day in some situation it will come from some external factor.

We should come up with a plan for how to compare speeds, and then try to generalize them so users in these situations can try them out for us to give us more facts.

added component::metrics/analysis performance priority::medium resolution::wontfix status::closed type::task labels

Jake suggested an stunnel on each side, meaning the client sets up an stunnel and the relay (or bridge) sets up an stunnel, such that the Tor traffic is encapsulated in a more generic ssl handshake. This would be a nice pluggable transport of its own, but it would also be a simple way for advanced users to compare speeds.

Next step is to find an stunnel commandline guru who knows how to use the damn thing.

Replying to arma:

Next step is to find an stunnel commandline guru who knows how to use the damn thing.

Define "guru"? Sebastian, Robert and I have all set up/configured stunnel and we might be able to answer some of your questions.

That's right.

I've been using Tor for almost all my worthy net traffic since 2 years ago and I was able to download through Tor at 45+KBps speed which is very good, considering that my bandwidth is 512Kbps.

Since 2-3 weeks ago, the speed of Tor (both downloading and surfing) has dropped significantly. Now all I get, is an average of 5-6KBps which is really awful.

I hope you folks find a way to improve Tor's speed. With VPN traffic being blocked at all since a month ago, our only hope is Tor.

Thank you all for your invaluable efforts.

Trac:
Username: bahman

Replying to runa:

Define "guru"? Sebastian, Robert and I have all set up/configured stunnel and we might be able to answer some of your questions.

What we need are specific instructions that can be run on the client side and the bridge side.

On the client side, we want to set up an stunnel that accepts incoming connections to localhost and forwards them, encrypted, to the remote side. Then the Tor client should configure that stunnel local socket as her bridge.

On the remote side, we want to accept incoming ssl connections, decrypt them, and then hand them to the local Tor relay. For example, fork a "nc localhost 9001" for each incoming connection after the handshake. That way the connection from the Tor client goes to the Tor bridge, but it transparently has another layer of encryption added and then removed in transit.

We'll want to try this on Tor bridges, not relays, due to bug #1776 (moved).

As a bonus, if this works I bet it will make bridges usable in China again (for now).

Trac:
Summary: Get better at comparing SSL speed in Iran to Tor speed to Hack up stunnel to test a transport that uses a vanilla SSL handshake

Trac:
Keywords: N/A deleted, performance added

Without loss of generality, assume that your bridge is at 1.2.3.4:

On the client side you would want to run: # stunnel -f -c -d 127.0.0.1:6000 -r 1.2.3.4:6001 And then in your torrc, set up your Bridge line to point to 127.0.0.1:6000.

On the relay side you would want to run: # stunnel -f -p server.pem -d 6001 -r localhost:5001 where server.pem is a file with a vanilla cert. chain and a private key. And then set up your torrc with'ORPort 5001'.

(PROTIP: port numbers can change)

I also coded an stunnel-like obfsproxy transport. You can find it in branch 'bug4248' of git://gitorious.org/obfsproxy/obfsproxy.git. As in the above example, on the server side you would do: $ obfsproxy moressl server 1.2.3.4:6001 127.0.0.1:5001 server.crt

and on the client side: $ obfsproxy moressl socks 127.0.0.1:6000 then add it as the ClientTransportPlugin of the Bridge at 1.2.3.4:6001.

We ran some tests from inside of Iran. We downloaded a 10MB file in 3 situations:

Connecting to bridge over Stunnel

curl --socks5 127.0.0.1:9050 http://hosntame/filename.zip -o test.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 26 10.0M 26 2729k 0 0 7947 0 0:21:59 0:05:51 0:16:08 8954^C

Connecting directly to Tor, no bridge, no stunnel

% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 24 10.0M 24 2532k 0 0 7366 0 0:23:43 0:05:52 0:17:51 10567^C

Connecting directly without Tor

% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 96 10.0M 96 9852k 0 0 28423 0 0:06:08 0:05:54 0:00:14 12211^C

Trac:
Username: mazda
Cc: twilde to twilde, mazda@redteam.io

That argues for "no significant difference between Tor and Tor+stunnel"

Meaning the slow-down that people are seeing in Iran is a combination of "Tor is slower than it was before" and "when Tor is slow, it is especially no fun on a slow link" (#4487 (moved)), and not due to any fancy "DPI but we won't block it we'll just throttle it" scheme.

It appears that They are throttling SSL, just not throttling Tor any more than other SSL.

Replying to rransom:

It appears that They are throttling SSL, just not throttling Tor any more than other SSL.

Oh hey, good point. We should get some runs of Tor+obfsproxy to compare.

Trac:
Cc: twilde, mazda@redteam.io to twilde, mazda@redteam.io, asn

Here is the results for obfuscated test:

on obfsproxy+tor:

curl --socks5 127.0.0.1:5000 http://00.00.00.00/testfile.zip -o day2.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 10.0M 100 10.0M 0 0 47929 0 0:03:38 0:03:38 --:--:-- 48169

on normal tor:

curl --socks5 127.0.0.1:9050 http://00.00.00.00/testfile.zip -o day2-2.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 10.0M 100 10.0M 0 0 113k 0 0:01:30 0:01:30 --:--:-- 123k

weird! isn't it? I've never experienced this speed over tor before! but at the very same time, on my other machine (Mac OS X). I'm experiencing pain over tor! pretty slow!

Direct connection:

curl http://00.00.00.00/testfile.zip -o day2-3.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 10.0M 100 10.0M 0 0 113k 0 0:01:29 0:01:29 --:--:-- 109k

I'm gonna test it once again...

on tor:

curl --socks5 127.0.0.1:9050 http://00.00.00.00/testfile.zip -o day2-4.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 10.0M 100 10.0M 0 0 25764 0 0:06:46 0:06:46 --:--:-- 38053

more realistic this time

so now I will delete my tor data to make sure everything is alright:

rm -rf ~/.tor/*

now will start obfsproxy and test again...

on obfsproxy+tor:

the result is... impressive!

curl --socks5 127.0.0.1:5000 http://00.00.00.00/testfile.zip -o day2-5.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 10.0M 100 10.0M 0 0 88378 0 0:01:58 0:01:58 --:--:-- 108k

direct connection (no proxy):

curl http://00.00.00.00/testfile.zip -o day2-6.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 10.0M 100 10.0M 0 0 124k 0 0:01:22 0:01:22 --:--:-- 123k

Trac:
Username: mazda

Closing tickets in Metrics/Analysis that have been created 5+ years ago and not seen progress recently, except for the ones that "nickm-cares" about.

Trac:
Resolution: N/A to wontfix
Status: new to closed

closed