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

tor and umts
by Stefan Kuttler 13 Aug '19

13 Aug '19

https://stackoverflow.com/questions/57268523/care-for-privacy-encrypted-bro…

1 0

tor and umts
by Stefan Kuttler 13 Aug '19

13 Aug '19

https://stackoverflow.com/questions/57268523/care-for-privacy-encrypted-bro…

1 0

Best (simple) obfs4 deployment url?
by Roger Dingledine 07 Aug '19

07 Aug '19

Hi Philipp! I am finishing up my Defcon slides, and I realized I don't know where to point people for setting up obfs4 bridges. Google sends me to https://support.torproject.org/operators/operators-6/ but I bet that's not up-to-date (but maybe it should become up-to-date). On the tor-relays list I see https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4… which is (a) a really long url, and (b) an intimidatingly long page. And I hear irl is working a 'tor-bridge' meta-deb: https://bugs.torproject.org/31153 So: assuming I want to tell a bunch of people to do something in a week and a half, using a url they can hastily scribble down from my slide, what should I tell them? :) It is ok if the url doesn't say the right thing today but we're confident it will say the right thing on the morning of Aug 8. Thanks, --Roger

2 3

The MASQUE circumvention protocol
by Philipp Winter 01 Aug '19

01 Aug '19

I found a more extensive description of the MASQUE protocol: <https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html> Here are my key take-aways after reading the draft: * MASQUE enables circumvention by hiding a circumvention proxy behind a web server, similar to Sergey's httpsproxy. Clients "unlock" the web server's circumvention feature by using the newly-proposed HTTP Transport Authentication Standard: <https://tools.ietf.org/html/draft-schinazi-httpbis-transport-auth-00> In a nutshell, clients need to send a CONNECT request with a transport authentication header to .well-known/masque/initial. Crucially, MASQUE defends against active probing by responding with "405 Method Not Allowed" to failed authentication attempts -- the same response one would get for an unexpected CONNECT request. This prevents censors from learning if a web server supports MASQUE. * Once a client "unlocked" a MASQUE server, one can tunnel several types of traffic over the MASQUE server. One can use it as an HTTP proxy, send DNS requests, and do both UDP and TCP proxying. * MASQUE supports QUIC over HTTP/3 and TLS 1.3 over HTTP/2. There is a fallback mechanism from HTTP/3 to HTTP/2 to provide a disincentive for censors to block QUIC or HTTP/3. * MASQUE only provides obfuscation and does not provide anonymity. The document suggests onion routing in Section 2.4 to work around this shortcoming. * MASQUE does not defend against traffic analysis but QUIC supports padding, so there's a mechanism to mitigate this problem. Traffic analysis defence is left for future work in Section 7.2. * QUIC has a "connection migration" feature that allows clients to seamlessly switch end-to-end connections from one MASQUE server to another. * Similar to onion services, MASQUE makes it possible to make available a server behind NAT by using a MASQUE server as a rendez-vous mechanism. There's an IETF mailing list for the project: <https://mailarchive.ietf.org/arch/browse/masque/> MASQUE may make a good pluggable transport and we should engage early to make this happen. I intend to suggest this idea on their mailing list soon. Cheers, Philipp

1 0

Resources related to user testing and screen recording
by David Fifield 14 Jul '19

14 Jul '19

These are in response to a conversation with phw and cohosh about observing how people use Tor Browser. Here are links relating to the 2015 UX Sprint, at which we did one-on-one observations of a few users. https://blog.torproject.org/ux-sprint-2015-wrapup https://trac.torproject.org/projects/tor/wiki/org/meetings/2015UXsprint The videos of the sessions are here: https://people.torproject.org/~dcf/uxsprint2015/ The source code for our screen recording setup is here. I'm attaching the README. https://www.bamsoftware.com/git/repo.eecs.berkeley.edu/tor-ux.git Here's a rough description of the whole process. We ran user experiments over two days. We were hampered by late recruiting (Berkeley only approved the experiment literally the day before) and we only had five participants, three on Saturday and two on Sunday. But that number turned out to be plenty because of how labor-intensive the process was. We had all the devs in a room downstairs with a projector. The experiments were run upstairs in a smaller room on a laptop. What we did was screencast the laptop screen to the projector downstairs (using VLC streaming through an SSH tunnel). Developers could watch user interactions live, and we also recorded the whole thing. We audio recorded the subjects' voices on handheld audio recorders (we encouraged them to think out loud as they were using the software). The idea was to transcribe the audio and add it to the screen recordings as subtitles. That was a huge amount of work, but the videos are really interesting and enlightening. We gave participants the choice of a Windows or Mac laptop. It happens that all of the chose Mac, though we had Windows ready to go. Windows was a big pain to set up with VLC and SSH; I might do that differently a second time. We originally planned to run up to two experiments simultaneously. That would have been way too hectic. It's a lot of work greeting people, doing paperwork, doing the experiment, making sure you reset the computer in between experiments--we really needed an extra person downstairs all that time. With more researchers (i.e., people allowed to interact with participants) it would be possible. We budgeted one hour of one-on-one time with each participant. It ended up taking between 15 and 30 minutes of actual experiment for each (that's how long the resultant videos are), but that doesn't count all the paperwork and setup time. 60 minutes of actual experiment would have been too long. It could be that long if it were not one on one. But also, there was high variance in how long things took to complete. Some users took longer to install than others. Another took a long time trying to find a specific UI element. The repo for our PETS 2017 paper is here: https://github.com/lindanlee/PETS2017-paper The screen capture videos from a pilot session of recording are here: https://github.com/lindanlee/PETS2017-paper/tree/master/sessions/pre/videos Scripts relating to setting up the simulated censorship firewall are here: https://github.com/lindanlee/PETS2017-paper/tree/master/experiment

1 0

"Dissecting Tor Bridges" NDSS'17 paper
by Philipp Winter 10 Jul '19

10 Jul '19

I skimmed Matic et al.'s NDSS'17 paper "Dissecting Tor Bridges: a Security Evaluation of Their Private and Public Infrastructures": <https://censorbib.nymity.ch/pdf/Matic2017a.pdf> Below are the points that stood out the most to me. Note however that the study is from 2017 and some numbers may no longer be valid. * With the exception of China and the U.S., default bridges served by far the most users. The popularity of default bridges makes them a single point of failure that is easy for censors to block. We have been losing default bridges over the last few months and should be recruiting new operators: <https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges> We have a list of criteria for new operators at the bottom of the page. If you are interested in running a default bridge, please get in touch. * Four OR ports (443, 8443, 444, and 9001) were used much more often than others. Today, 19% of bridges use port 9001 and 17% use port 443. Port 9001 is problematic because it is an attractive target for Internet-wide scans. So is port 443 but it has some merit for users who seek to circumvent corporate firewalls. Is there any reason at all to have bridges listen on port 9001? If not, we should ask these operators to pick a new port. * If a censor discovers a bridge and the bridge runs an SSH server, the censor can fetch its fingerprint and use Shodan to find other SSH servers with the same fingerprint. These servers may also be running bridges. Bridge-specific SSH keys would fix this problem. We may want to create a "bridge opsec guide" for subtle issues like these. * Shodan and Censys are search engines for Internet-wide scans. The authors were successful in using these datasets to find 35% of "public" bridges, i.e., bridges that publish their server descriptor to the bridge authority. The idea is to look for certificates that resemble a Tor bridge and then actively probe the port to confirm this suspicion. This is a tricky balancing act: most bridges should probably avoid the ports that Shodan and Censys scan but we need a few of them for users whose firewalls whitelist these ports. * Many bridges run transports that are both resistant *and* vulnerable to the GFW's active probing attacks. The vulnerable protocols are a liability to the resistant protocols. We fixed this issue in BridgeDB (#28655) but it remains a problem for Internet-wide scans: if a censor discovers a bridge via a port 9001 scan, obfs4's probing-resistance doesn't help. The need to haven an open OR port (#7349) remains a painful issue. Also, wouldn't it be useful to have a mechanism to instruct bridges to stop serving a transport? At this point, there is no reason to still serve obfs2, obfs3, or ScrambleSuit. Cheers, Philipp

1 0

Meeting on July 4 cancelled
by Philipp Winter 25 Jun '19

25 Jun '19

Let's cancel the anti-censorship meeting on July 4. It's a national holiday in the U.S. and several of our developers won't be around. Cheers, Philipp

1 0

Future of Traffic obfusication
by Free Beer 12 Jun '19

12 Jun '19

> Neat. Yes, and all built with existing components. In terms of your chart of Fri May 31 05:02:35 UTC 2019, the original Shadowsocks (SS) was at the look-like-nothing end. ShadowsocksR (SSR), by contrast, offers various experiments in protocol mimicry. Of course, as the censorship arms race escalates, you have to become more and more accurate in your mimicry. There are mutterings on the Internet that _some_ original SS servers are now being detected. No one knows for sure what methods the Great Firewall (GFW) uses. Entropy analysis is one possibility. I see this was mentioned in your reference "Seeing through Network-Protocol Obfuscation." Certain detection methods apply only to private servers. For example, the GFW may simply look to see whether the destination IP address belongs to one of the popular low-cost VPS providers with good latency to China. Traffic metrics may also play a part. If all of your traffic goes to one IP address, and you are the only person who sends traffic that IP address, then it sure looks like some kind of private proxy. On the other hand, certain detection methods apply only to a public project like Tor. These include picking bridge IP addresses out of Github, and requesting new bridges by email every day for as long as it takes to enumerate them. In both cases, we could call such methods "obfuscation agnostic." In other words, it doesn't matter how sophisticated your obfuscation techniques become. You need to think about protecting your server addresses from detection. Sent with ProtonMail Secure Email.

1 0

Future of Traffic obfusication
by Free Beer 10 Jun '19

10 Jun '19

> does anyone have any good predicitions about where > the traffic obfusication is in 5 years ? The experience in China is that any given anti-censorship method will be effective for only 4 years before it is blocked. Therefore, what will work in 5 years time has not yet been invented. :) Just out of interest, for countries where both Tor and Tor bridges are blocked by a firewall, you can configure Tor Browser to use ShadowsocksR (SSR) as a proxy server. I put a quick 1'19" proof-of-concept video up on YouTube with the title Tor浏览器+ShadowsocksR(SSR)客户端配置 Client Configuration: https://www.youtube.com/watch?v=VRGZ4dOYv1Q Sent with ProtonMail Secure Email.

2 1

Re: [anti-censorship-team] Future of Traffic obfusication
by Flipchan 08 Jun '19

08 Jun '19

Is there any research or developement done in anti correlation protocols such as system based on ring signatures such as the ring transactions in monero? On June 7, 2019 3:00:09 PM GMT+03:00, anti-censorship-team-request(a)lists.torproject.org wrote: >Send anti-censorship-team mailing list submissions to > anti-censorship-team(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team > >or, via email, send a message with subject or body 'help' to > anti-censorship-team-request(a)lists.torproject.org > >You can reach the person managing the list at > anti-censorship-team-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of anti-censorship-team digest..." > > >Today's Topics: > > 1. Future of Traffic obfusication (Flipchan) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 06 Jun 2019 22:53:32 +0300 >From: Flipchan <flipchan(a)riseup.net> >To: anti-censorship-team(a)lists.torproject.org >Subject: [anti-censorship-team] Future of Traffic obfusication >Message-ID: <1FA6176E-CDB2-483C-B6AD-7987A26371AF(a)riseup.net> >Content-Type: text/plain; charset="utf-8" > >Hey all, > >I am working on a podcast episode about traffic obfusication, and there >is a lot of nice whitepapers talking about potentially anonymous ways >of shuffeling traffic. > >However, I am intresting in the future of traffic obfusication and the >large problems that traffic obfusication faces today, does anyone have >any good predicitions about where the traffic obfusication is in 5 >years ? > >Or do we wait and see for the next big Whitepaper and PoC code ? > >What do you think? > > >Thanks in advance >Sincerely >Flipchan > >

1 0