[tor-bugs] #33336 [Circumvention/Snowflake]: Deploy a Turbo Tunnel–aware Snowflake bridge

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Feb 20 18:04:09 UTC 2020


#33336: Deploy a Turbo Tunnel–aware Snowflake bridge
-------------------------------------+--------------------------
 Reporter:  dcf                      |          Owner:  dcf
     Type:  task                     |         Status:  accepted
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  turbotunnel              |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+--------------------------

Comment (by dcf):

 My observations from running the quic and kcp browsers more or less
 continuously since yesterday.

  * The experience is still pretty hit or miss. Sometimes you get a good
 proxy and cruise on it for a while; other times you get delays of several
 minutes caused by a series of non-working proxies—not slow proxies, but
 ones that never send any downstream data at all. I don't know why so many
 proxies should be broken in this way; for me it must be over 50% of them.
  * I got to the point of continuously tailing both snowflake-client logs
 to get some insight into what was happening.
  * The worst is when a series of bad proxies causes a delay of a few
 minutes with no data transfer; in that case tor gets into a "No running
 bridges" bridges state that it is hard to coax out of. When this happens
 it's not evident in the snowflake-client log; you have to go to
 about:preferences#tor and look at the tor log. It may look like this:
    {{{
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $3F50D11DE55C028B8F3EFC272BB1CD9138C1F9A4~0x616e6f6e at 178.17.171.78.
 Retrying on a new circuit.
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $3F50D11DE55C028B8F3EFC272BB1CD9138C1F9A4~0x616e6f6e at 178.17.171.78.
 Retrying on a new circuit.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
    }}}
    Or this:
    {{{
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $6B062B0FDFEAC3C6F9203FB9584451E295574DAD~idideditTheconfig at
 51.15.37.97. Retrying on a new circuit.
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $7761DDC7EB1BE26D4155F74A15F12C32A36FE0F2~CalyxInstitute09 at
 162.247.74.217. Retrying on a new circuit.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
    }}}
    When this happens, I usually have luck in going to
 about:preferences#tor, momentarily switching from snowflake to obfs4, then
 switching back to snowflake. This restarts the snowflake-client process
 and seems to cause tor to have a fresh look at its bridges.
  * I'm not noticing a ton of subjective difference in the feel of the two
 browsers. The main difference I have seen is that the quic one
 occasionally spends a few minutes at 100% CPU: #33401.
  * It may be my imagination, but I get the impression that everything
 works better while the connection is being used. Initially my impression
 was positive as I was trying to stress the system by having videos playing
 in the background. Then the experience became more frustrating as I tried
 normal text browsing and I encountered the occasional delays mentioned
 above. It made me think that perhaps there is something in the proxy that
 drops idle connections, but I didn't find anything like that. It's
 possible that this is my imagination and that my initial impression was
 just getting good luck with proxies.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33336#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list