- anti-censorship-team - lists.torproject.org

Next anti-censorship meeting on Jan 2nd
by Philipp Winter 19 Dec '19

19 Dec '19

Let's reconvene on Thursday, January 2nd. It will no longer be 2019, so I created a new meeting pad for us and populated it with the content of our old pad: <https://pad.riseup.net/p/tor-anti-censorship-keep> The old pad now also links to the new one. Cheers, Philipp

1 0

Nov 27 (Thursday) meeting cancelled
by Philipp Winter 27 Nov '19

27 Nov '19

This week's meeting falls on Thanksgiving, a U.S. holiday, so several of us won't be around. Let's cancel our Thursday meeting and meet again next week, on December 4. Cheers, Philipp

1 0

day for roadmaping January & February?
by Gaba 26 Nov '19

26 Nov '19

Hi! We need to work on roadmapping January and February, mostly for the sponsor 28. Can you all meet on December 16th or 17th? cheers, gaba -- Project Manager: Network, Anti-Censorship and Metrics teams gaba at torproject.org she/her are my pronouns GPG Fingerprint EE3F DF5C AD91 643C 21BE 8370 180D B06C 59CA BD19

4 4

raw.githubusercontent.com blocked in China (affects GetTor)
by David Fifield 21 Nov '19

21 Nov '19

It looks like the domain raw.githubusercontent.com was blocked in China a few days ago. https://ntc.party/t/raw-githubusercontent-com-blocked-in-china-since-2019-1… This affects GetTor, because it uses links like https://github.com/TheTorProject/gettorbrowser/raw/torbrowser-releases/torb… which redirect to https://raw.githubusercontent.com/TheTorProject/gettorbrowser/torbrowser-re…

2 2

IRC keywords to reach anti-censorship team
by Philipp Winter 14 Nov '19

14 Nov '19

Other teams have started to use IRC keywords to reach team members, e.g.: "network-team: somebody review #foo". We discussed this in today's meeting and agreed to use both "ac-team" and "anti-censorship-team" for our team: <http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-11-14-18.00.html> Cheers, Philipp

1 0

Cancelling IRC meeting on November 7
by Philipp Winter 30 Oct '19

30 Oct '19

Both Cecylia and I will be travelling and won't be able to host the anti-censorship meeting on November 7. Let's cancel this one. Cheers, Philipp

1 0

Turbo Tunnel in obfs4proxy (survives TCP connection termination)
by David Fifield 21 Oct '19

21 Oct '19

I posted this at https://github.com/net4people/bbs/issues/14#issuecomment-544747519 but it's relevant to anti-censorship in Tor. Here are proof-of-concept branches implementing the turbo tunnel idea in obfs4proxy, one using kcp-go/smux and one using quic-go: * https://dip.torproject.org/dcf/obfs4/tree/reconnecting-kcp * https://dip.torproject.org/dcf/obfs4/tree/reconnecting-quic As diffs: * [Changes needed to add kcp-go/smux to plain obfs4proxy](https://dip.torproject.org/dcf/obfs4/compare/aa7313b7eb78b7546a… * [Changes needed to adapt kcp-go/smux to quic-go](https://dip.torproject.org/dcf/obfs4/compare/b5d6895542b8fce929739… Using either of these branches, your circumvention session is decoupled from any single TCP connection. If a TCP connection is terminated, the obfs4proxy client will establish a new connection and pick up where it left off. An error condition is signaled to the higher-level application only when there's a problem establishing a new connection. Otherwise, transient connection termination is invisible (except as a brief increase in RTT) to Tor and whatever other application layers are being tunnelled. I did a small experiment showing how a Tor session can persist, despite the obfs4 layer being interrupted every 20 seconds. I configured the "little bastard" connection terminator to forward from a local port to a remote bridge, and terminate connections after 20 seconds. ``` lilbastard$ cargo run -- -w 20 127.0.0.1:3000 192.81.135.242:4000 ``` On the bridge, I ran tor using either plain obfs4proxy, or one of the two turbo tunnel branches. (I did the experiment once for each of the three configurations.) ``` DataDirectory datadir.server SOCKSPort 0 ORPort auto BridgeRelay 1 AssumeReachable 1 PublishServerDescriptor 0 ExtORPort auto ServerTransportListenAddr obfs4 0.0.0.0:4000 ServerTransportPlugin obfs4 exec ./obfs4proxy -enableLogging -unsafeLogging -logLevel DEBUG # ServerTransportPlugin obfs4 exec ./obfs4proxy.kcp -enableLogging -unsafeLogging -logLevel DEBUG # ServerTransportPlugin obfs4 exec ./obfs4proxy.quic -enableLogging -unsafeLogging -logLevel DEBUG ``` On the client, I configured tor to use the corresponding obfs4proxy executable, and connect to the bridge through the "little bastard" proxy. (If you do this, your bridge fingerprint and cert will be different.) ``` DataDirectory datadir.client SOCKSPort 9250 UseBridges 1 Bridge obfs4 127.0.0.1:3000 94E4D617537C3E3CEA0D1D6D0BC852B5A7613B77 cert=6rB8kVd981U0G2b9nXioB5o0Zu7tDpDkoZyPe2aCmqFzGmfaSiNIfQvkJABakH+DfYwWRw iat-mode=0 ClientTransportPlugin obfs4 exec ./obfs4proxy -enableLogging -unsafeLogging -logLevel DEBUG # ClientTransportPlugin obfs4 exec ./obfs4proxy.kcp -enableLogging -unsafeLogging -logLevel DEBUG # ClientTransportPlugin obfs4 exec ./obfs4proxy.quic -enableLogging -unsafeLogging -logLevel DEBUG ``` Then, I captured traffic for 90 seconds while downloading a video file through the tor proxy. In the "plain obfs4proxy" case, the download stopped after the first connection termination at 20 s. Every 20 s after that, there was a small amount of activity, which was tor reconnecting to the bridge (and the resulting obfs4 handshake). But it didn't matter, because tor has already signaled the first connection termination to the application layer, which gave up: ``` curl: (18) transfer closed with 111535615 bytes remaining to read ``` In comparison, the "kcp" and "quic" cases kept on downloading, being only momentarily delayed by a connection termination. Notes: * How this works architecturally, on the client side, we replace the original TCP Dial call with either kcp.NewConn2 or quic.Dial, over an abstract packet-sending interface (clientPacketConn). clientPacketConn runs a loop that repeatedly connects to the same destination and exchanges packets (represented as length-prefixed blobs in a TCP stream) as long as the connection is good, reporting an error only when a connection attempt fails. On the server side, we replace the TCP Listen call with either kcp.ServeConn or quic.Listen, over an abstract serverPacketConn. serverPacketConn opens a single TCP listener, takes length-prefixed packets from *all* the TCP streams that arrive at the listener, and feeds them into a *single* KCP or QUIC engine. Whenever we need to send a packet for a particular connection ID, we send it on the TCP stream that most recently sent us a packet for that connection ID. * There's no need for this functionality to be built into obfs4proxy itself. It could be done as a separate program: ``` ------------ client ------------ ------------ bridge ------------ tor -> turbotunnel -> obfs4proxy -> internet -> obfs4proxy -> turbotunnel -> tor ``` But this kind of process layering is cumbersome with pluggable transports. * I'm passing a blank client IP address to the pt.DialOr call—this information is used for geolocation in Metrics graphs. That's because an OR connection no longer corresponds to a single incoming IP address with its single IP address—instead it corresponds to an abstract "connection ID" that remains constant across potentially many TCP connections. In order to make this work, you would have to define some heuristic such as "the client IP address associated with the OR connection is that of the first TCP connection that carried that connection ID."

1 0

IPv6 Snowflake broker (#29258) IP addresses and SSH key fingerprints
by David Fifield 17 Oct '19

17 Oct '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 2019-10-17 This is a signed statement of the IP addresses and SSH host key fingerprints of the Snowflake broker set up by David Fifield at https://bugs.torproject.org/#comment:11. 37.218.245.111 2a00:c6c0:0:154:4:d8aa:b4e6:c89f RSA: 2048 SHA256:dp0Xo/oN1qZfMuZnqgKEbeOsbU2qpDR60B5MLIRaAgg DSA: 1024 SHA256:DF5ofogjGur02gv8/ciU3wFA+YHNuAhUlel9Uv2KBlo ECDSA: 256 SHA256:6cskO6ch/kv2RbIMhTdwqpsd9vB8npzlZTlkWZJLoek ED25519: 256 SHA256:fEkLvmu5woTvU6162I8Jxd2eHzsTnBshumtWICclWA4 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeXoyauxKR4rwUMw64rk9gVzTiOUFAl2ormoACgkQ4rk9gVzT iOX7xQ/+KyWHU7f5Oj2zFFVFu/vkD2xNIDEuPgnAUmVp879QnfzqmHxBifNzgpXQ t+357gSWlMAHP6IO0spnKxQqFsugvH3QqH5fyEXmEKQcJw7UI5VYNR5aGd7soSOx meHtgVkmeyWJDNZZSjVrk9C0nnEnteOXMx02NVD4kC1hJkSBvOJT4+M3Ekxx0nnQ AOfc7ZEBhchEMYsf2wxY04O0dR4HCgwcRFUGV+gT5bKw4eoqT+0sMetMzi5CHAqd EjsRQhDCHOp1v7xkkxx0lMOKPL4IYQI4l5qOIMWfpFS3ZwWX18bm3qK4UsDVAxIJ FouPEuVz7CAsLrlc5hnaDrmM2VsH8hqRFW4PHhmycaHVrW1AKkt0h/qHxDfpIkgK xGNbROcpzfV3FmqGWe09sx1aSLI34nMzIPX3aB6EmZ3Qn3Dx3VZExrBQSlcJ5NLy 3fFvqEpOhRheuE4ohD48/jfj0hsX/Sqc5cKNcmQFPbjk3T2LzUx8TYsNMq/Us0NC XrNk3ph5ydssMCLSEZqFV+xTY/08u6bKMYyxrC7bSsRJo1WIBLOVlWbHVYc6WGgD i/XCDMOXSFawZVIQm5PJiqR87y5q9RBnitd31uNnYZLlty3SFvj2H6PqSu7iIw46 I5Gc/rPxRcWggjOOXxCm0IiTqnM94WgoWWMRFNpQqHzTio+J6fc= =sJTV -----END PGP SIGNATURE-----

1 0

obfs4 bridge option on eclips.is
by David Fifield 14 Oct '19

14 Oct '19

While setting up a new VPS on eclips.is, which is the service we use to host the Snowflake broker and bridge, I noticed that they have a preconfigured option to set up an obfs4 bridge. (And an Outline server, which is the Shadowsocks-based VPN from Jigsaw.)

1 0

Summary of Point Break (Jansen et al. USENIX Security '19) as it pertains to bridges
by David Fifield 26 Aug '19

26 Aug '19

Rob Jansen, Tavish Vidya, and Micah Sherr have a paper about bandwidth-based DoS against Tor. Section 5 is about default bridges. https://www.usenix.org/conference/usenixsecurity19/presentation/jansen https://www.usenix.org/system/files/sec19-jansen.pdf#page=6 While elsewhere in the paper they discuss in-protocol attacks, in the context of bridges they limit themselves to attacks using third-party paid "stresser" DoS services, which you can rent for about $1/Gbps/hour (Section 3.1). They looked at the default bridges in Tor Browser 8.0.3 (October 2018). Only 12 of 25 default obfs4 bridges were working. (I think most of the non-working bridges have since been pruned, e.g. in #29378, #30264.) The median bandwidth of the 12 working bridges was 368 KB/s, with a large variance: minimum of 67 KB/s and maximum of 1190 KB/s. Besides the default bridges, they requested 135 bridges from BridgeDB, and found that only 70% (95/135) of them worked. (This has also been at least partially addressed by #30441.) BridgeDB bridges are faster than default bridges, with a median bandwidth of closer to 600 KB/s (Figure 1). They estimate that disabling the 12 default obfs4 bridges would require 30 stresser jobs, at a rate of $22/hour or $17K/month. If all users of default obfs4 bridges switched to BridgeDB bridges, the median bandwidth of BridgeDB bridges would slow down to under 100 KB/s (Figure 2). If even half of default obfs4 users switch to using meek, the cost to operate meek will at least double (Figure 3).

3 3