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

Next anti-censorship reading group: 21 January 2021
by Cecylia Bocovich 20 Jan '21

20 Jan '21

Hey everyone! We will discuss "Early Detection of Censorship Events with Psiphon Network Data" two weeks from today at our team meeting on 2021-01-21, at 16 UTC. Paper link: https://tics.site/proceedings/2019a/icn_2019_7_10_38005.pdf Questions to ask and goals to have: - What can we learn from this work? - Are there immediate actions we can take based on this work? - Are there long-term actions we can take based on this work? - Is there future work that we want to call out, in hopes that others will pick it up? Hope to see you all there! Cecylia

1 1

DDoS on Greenhost, may affect Snowflake
by David Fifield 23 Dec '20

23 Dec '20

Greenhost sent an email saying that since last 2020-12-17, there has been a DDoS attack against their infrastructure. This may affect Snowflake, because the broker and bridge are hosted by Greenhost in Amsterdam. > Please bear with us as Greenhost and the eclips.is platform are > suffering from some of the largest DDoS attacks we have faced. > > Between Thursday and now we have seen targeted attacks on one of our > users and directly at Greenhost. > > Our upstream provider in Miami has unfortunately completely dropped > the eclips.is infrastruccture routing as they could not withstand the > attacks. We are working to put that connectivity back up as we speak. > > The situation in Amsterdam is more under our control, and both > Eclips.is and Greenhost networks are available as of writing. 2020-12-17 09:10 outage caused by a major DDOS attack https://status.greenhost.net/incidents/19 > Since 10:10 CET, we have been experiencing outage caused by a major > DDOS attack. > > All VPSes, webhosting and emailservers were affected by this outage. > > We have deflected the attack and worked to recover all systems. 2020-12-20 15:00 Repeated DDoS attacks on our infrastructure https://status.greenhost.net/incidents/20 > After the DDoS attack last Thursday we did see recurring attacks of > increasing magnitude on our infrastructure. We are working through the > weekend with our technical service providers to increase resilience of > our network. We will update you as the situation progresses. At this > point our services are operational.

2 2

Join the Minima community!
by Ryan Hennebry 14 Dec '20

14 Dec '20

Hi Tor Community, I’m the Community Manager of Minima, a cryptocurrency project based in London. Minima is a PoW base-layer blockchain protocol with a novel design, that runs entirely on mobile devices. Since every user runs a full node that validates and constructs the chain via an app, the protocol will be able to reach a user base not yet possible with any other blockchain protocol. This will allow our network to be as decentralised as possible, ultimately providing individuals a peer-to-peer censorship-resistant network for the transfer information and value. Our founder and lead developer Paddy Cerri built the Minima blockchain, and we are now entering testnet phase. Since Paddy’s true vision is to build a network where individuals have the freedom to send information and value without censorship, I thought that our protocol may be of interest to you. I wondered if any of you would be interested in helping us build censorship-resistant applications on the Minima protocol, debugging our code, or simply joining our community and learn more about crypto. I would love for you to join our discord community if you’re interested: https://discord.gg/SgvQ6mc Also, here are some resources that will give you more insight into Minima & Paddy: https://minima.global/blog/freedom https://minima.global/blog/blockchains-in-a-bitcoin-world-by-paddy-cerri-at… Thank you for your time and I look forward to meeting you all. Best, Ryan Hennebry / Community Manager ryan.hennebry(a)minima.global / +44 (0) 751 0989 043 Minima Unter Altstadt 28, 6300 Zug (Switzerland) 14-18 Great Titchfield Street, London, W1W8BD (UK) www.minima.global

1 0

Next anti-censorship reading group: 3 Dec 2020
by Cecylia Bocovich 19 Nov '20

19 Nov '20

Hey everyone! We will discuss "Poking a Hole in the Wall: Efficient Censorship-Resistant Internet Communications by Parasitizing on WebRTC" two weeks from today at our team meeting on 2020-12-03, at 16 UTC. Paper link: https://dl.acm.org/doi/pdf/10.1145/3372297.3417874 Questions to ask and goals to have: - What can we learn from this work? - Are there immediate actions we can take based on this work? - Are there long-term actions we can take based on this work? - Is there future work that we want to call out, in hopes that others will pick it up? Hope to see you all there! Cecylia

1 0

Next anti-censorship reading group, 12 Nov 2020
by Cecylia Bocovich 09 Nov '20

09 Nov '20

Hey everyone! We will discuss "The use of TLS in Censorship Circumvention" at our next team meeting on 2020-11-12, at 16 UTC. Paper link: https://tlsfingerprint.io/static/frolov2019.pdf Questions to ask and goals to have: - What aspects of the paper are questionable? - Are there immediate actions we can take based on this work? - Are there long-term actions we can take based on this work? - Is there future work that we want to call out, in hopes that others will pick it up? Hope to see you all there! Cecylia

1 0

Anti-censorship meeting notes, 1 October 2020
by Cecylia Bocovich 05 Oct '20

05 Oct '20

Hey everyone! Here are the meeting logs: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-10-01-15.58.html And the meeting pad: Anti-censorship work meeting pad -------------------------------- Next meeting: Thursday October 1st 16:00 UTC Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) == Goal of this meeting == Weekly checkin about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at Tor. == Links to Useful documents == Our anti-censorship roadmap: Roadmap: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/boards The anti-censorship team's wiki page: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/home Past meeting notes can be found at: https://lists.torproject.org/pipermail/tor-project/ Tickets that need reviews: from sponsors we are working on: All needs review tickets: https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… Sponsor 30 https://gitlab.torproject.org/groups/tpo/-/milestones/4 https://gitlab.torproject.org/groups/tpo/-/milestones/7 https://gitlab.torproject.org/groups/tpo/-/milestones/5 https://gitlab.torproject.org/groups/tpo/-/milestones/6 Sponsor 28 must-do tickets: https://gitlab.torproject.org/groups/tpo/-/milestones/10 possible tickets: https://gitlab.torproject.org/groups/tpo/-/issues?scope=all&utf8=%E2%9C%93&… Anti-censorship related tickets that we want other teams to fix: https://pad.riseup.net/p/tor-anti-censorship-tickets-keep <-- it will be moved into gitlab with TPO labels Public bug-reporting pad: https://pad.riseup.net/p/tor-anti-censorship-bugs-keep == Announcements == Kyle MacMillan, Jordan Holland, and Prateek Mittal published a report on Snowflake distinguishability. https://arxiv.org/abs/2008.03254 == Discussion == How can we improve our terminology for bridges? https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/8 == Actions == == Interesting links == == Reading group == We will discuss "" on Questions to ask and goals to have: What aspects of the paper are questionable? Are there immediate actions we can take based on this work? Are there long-term actions we can take based on this work? Is there future work that we want to call out, in hopes that others will pick it up? == Updates == Name: This week: - What you worked on this week. Next week: - What you are planning to work on next week. Help with: - Something you need help with. phw: This week (2020-10-01): Reviewed antonela's Tor Browser design proposal for better circumvention. https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/40… Helping out with DRL grant application. More work on rdsys; thinking about how feedback loop for blocked bridges should be handled. Wrapped up bridgestrap MVP. Next week: Help with: cecylia (cohosh): last updated 2020-10-01 Last week: - finished preparations for next sponsor 28 evaluation of snowflake - reviewed bridgedb#31871 - reviewed anti-censorship/trac#31874 - implemented fix for snowflake#33157 - checked on tests running for snowflake#32657 This week: - revisit multiplexing ticket - revisit NAT-punching problems for symmetric NATs - write up collected snowflake throughput data from last month and draw some useful conclusions - catch up on rdsys work - follow up with guardian project on their snowflake integration work Needs help with: - review of snowflake!12 - review of snowflake-webext!4 juggy : This week: - Got very basic "suggested readings" list up and running here : https://jugheadjones10.github.io/anti-censorship-reading/ Next week: - Keep studying BridgeDB to write architectural overview Help with: - Open issues here (https://github.com/jugheadjones10/anti-censorship-reading ) for papers/resources/readings that you think might be useful for newcomers arlolra: 2020-06-11 Last week: - Next week: - follow ups to #33365 - start on #31201 Help with: - dcf: 2020-10-01 Last week: - merged a patch from Peter Gerber to expand the set of IP addresses Snowflake considers local (for stripping from SDP offers) https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Azure CDN bookkeeping Next week: Help with: - is anything further needed for Azure CDN account access? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Antonela: 2020-08-27 This week: - Wrapping Babatunde's research on the use of circumvention tools during internet censorship in Africa. Wrapping Personas for s30 with it. For september: - We are planning interviews with users in China to run our bridges discovery issues script in real time. We discussed to include TBA + snowflake as a task for users to run over a week or two and report back. https://gitlab.torproject.org/tpo/ux/research/-/issues/4 - I still have bridges.tpo to lektor issue open - More work on UX/UI for TB 10.0/10.5 - Review Salmon related tickets (im late with it!) agix:2020-10-01 Last week: -Still on #34218 (Should finish it soon though) -Started with #5 (rdsys) -Read this weeks paper Next week: -Finish both tickets Help with: - hanneloresx: 2020-09-17 Last week: - Start on #33727 - Continue investigating and respond to comments on #32117 Next week: - Continue last week's work. Help with: - thymbahutymba: 2020-04-02 Last week: - CI/CD pipeline for multiarch docker images, which has a problem with the apt tor version even though the apt repository have been changed into the Dockerfile. Next week: Help with: HashikD: 2020-08-27 This week: - GSoC blog Next week: - Away on exams Help with: -

1 0

Next steps for unclassifiable protocols
by Roger Dingledine 04 Oct '20

04 Oct '20

Hi folks, Here are some brainstorming thoughts to get us started improving our "unclassifiable protocols" idea. ---------------------------------------------------------------------- For context, right now we have essentially one deployed design in this space, which is obfs4: https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4… This protocol does a short handshake (one client message, one server message) to establish session keys, then it just sends bytes back and forth with an (additional) layer of encryption so no payload bytes assist an attacker with doing content-based protocol classification. ---------------------------------------------------------------------- One of the more thorough analyses of obfs4 comes from the FTE folks: https://www.freehaven.net/anonbib/#ccs2015obfsdetection where they show a classifier that assesses entropy of the first server-side packet, plus looking at the length of that initial message, and they can consistently pick out obfs4 flows with only a 0.25% false positive rate compared to background traffic they recorded at their university. That false positive rate is where it gets interesting: it sounds good until we realize that it means it flags 1 in every 400 flows as being obfs4, i.e. it falsely tags about 36000 flows in the 14M flow dataset. And the false positives aren't randomly distributed either: 1.22% of their SSL flows are falsely tagged as obfs4, and it's the ones where the SNI in the SSL handshake has a lot of entropy (because everything else in the SSL handshake is already random). Also, entire protocols like RTMP get caught up and tagged as obfs4, because their handshake starts out with a block of random bytes. A key takeaway is that if they ran this classifier, with its high true positive rate and low false positive rate, on a large country's network traffic, approximately none of the flows that it would tag as obfs4 would actually be obfs4. Their Section 7 in that paper has a good discussion of the base rate issues and how they apply here. Are there other papers that design or analyze classifiers for obfs4? ---------------------------------------------------------------------- The good news: It would seem that obfs4 is most effective in the "long tail of varied traffic" scenario. That is, considering the spectrum between "small corporate network" and "China backbone", obfs4 needs that more broad background traffic in order to make its false positives too painful to block. The bad news: I still worry about an attack that puts together many building blocks, each of which individually is like the "1% false positive rate" classifier in the above paper, but that together drive their false positive rate low enough that blocking is safe to do. One observation there is that the more complexity there is to a protocol, the harder it is to "really" look like it, i.e. to match it in all dimensions at once. Consider this lovingly handcrafted graph, where the X axis is how thoroughly we try to look like some expected protocol, and the Y axis is how close we can get to making the adversary unwilling to block us: 1_| |_1 | | |\ /| | \ / | | \ / | | \ / | 0_| \___________________________________________/ |_0 | | There's a huge valley in the middle, where we're trying to look like something, but we're not doing it well at all, so there is little damage from blocking us. The ramp on the right is the game that FTE tries to play, where in theory if they're not perfectly implementing their target protocol then the adversary can deploy a distinguisher and separate their traffic from the "real" protocol, but in practice there are enough broken and weird implementations of the protocol in the wild that even being "close enough" might cause the censor to hesitate. And the ramp on the left is our unclassifiable traffic game, where we avoid looking like any particular expected protocol, and instead rely on the long tail of legitimate traffic to include something that we blend with. Observation: *both* of these ramps are in the "broken in theory, but works in practice" situation. I started out thinking it was just the obfs4 one, and that the FTE one was somehow better grounded in theory. But neither side is actually trying to build the ideal perfect protocol, whatever that even is. The game in both cases is about false positives, which come from messy (i.e. hard to predict) real-world background traffic. One research question I wrestled with while making the graph: which ramp is steeper? That is, which of these approaches is more forgiving? Does one of them have a narrower margin for error than the other, where you really have to be right up against the asymptote or it doesn't work so well? For both approaches, their success depends on the variety of expected background traffic. The steepness of the right-hand (look-like-something) ramp also varies greatly based on the specific protocol it's trying to look like. At first glance we might think that the more complex the protocol, the better you're going to need to be at imitating it in all dimensions. That is, the more aspects of the protocol you need to get right, the more likely you'll slip up on one of them. But competing in the other direction is: the more complex the protocol, the more broken weird implementations there could be in practice. I raise the protocol complexity question here because I think it has something subtle and critical to do with the look-like-nothing strategy. Each dimension of the protocol represents another opportunity to deploy a classifier building block, where each classifier by itself is too risky to rely on, but the composition of these blocks produces the killer distinguisher. One of the features of the unclassifiable protocol that we need to maintain, as we explore variations of it, is the simplicity: it needs to be the case that the adversary can't string together enough building-block classifiers to reach high confidence. We need to force them into building classifiers for *every other protocol*, rather than letting them build a classifier for our protocol. (I'll also notice that I'm mushing together the notion of protocol complexity with other notions like implementation popularity and diversity: a complex proprietary protocol with only one implementation will be no fun to imitate, but the same level of complexity where every vendor implements their own version will be much more workable.) ---------------------------------------------------------------------- I've heard two main proposed ways in which we could improve obfs in theory -- and hopefully thus in practice too: (A) Aaron's idea of using the latest adversarial machine learning approaches to evolve a traffic transform that resists classifying. That is, play off the classifiers with our transform, in many different background traffic scenarios, such that we end up with a transform that resists classifying (low true positive and/or high false positive) in many of the scenarios. (B) Philipp's idea from scramblesuit of having the transform be parameterized, and for each bridge we choose and stick with a given set of parameters. That way we're not generating *flows* that each aim to blend in, but rather we're generating bridges that each aim to blend differently. This diversity should adapt well to many different background traffic scenarios because in every scenario some bridges might be identified but some bridges will stay under the radar. At first glance these two approaches look orthogonal, i.e. we can do both of them at once. For example, Aaron's approach tells us the universe of acceptable parameters, and Philipp's approach gives us diversity within that universe. Aaron: How do we choose the parameter space for our transforms to explore? How much of that can be automated, and how much needs to be handcrafted by subject-matter-experts? I see how deep learning can produce a magic black-box classifier, but I don't yet see how that approach can present us with a magic black-box transform. And as a last note, it would sure be nice to produce transforms that are robust relative to background traffic, i.e. to not be brittle or overfit to a particular scenario. Otherwise we're giving up one of our few advantages in the arms race, which is that right now we force the censor to characterize the traffic -- including expected future traffic! -- and assess whether it's safe to block us. There. Hopefully some of these ideas will cause you to have better ideas. :) --Roger

2 2

Metrics to watch for Salmon feedback loop
by Roger Dingledine 29 Sep '20

29 Sep '20

While brainstorming for a recent funding proposal, I wrote up this list of "Things we should measure to track our impacts/success" in the context of the Salmon bridge distribution strategy. Or to put it another way, these are questions I'll be asking phw et al to understand how things are going, once we deploy it. Some of the questions are variations on others, i.e. a single data source can answer several of them. So it's probably better framed as "questions to track" rather than "data sources we should collect". (1a) how many obfs4 / httpt bridges are running total? Bridges report their existence to the bridge authority, and bridgedb/rdsys aggregate them and send them to the metrics datasets. So we should already have these numbers. (1b) out of those, how many are we distributing via salmon? This is a parameter that we choose, and we will choose it based on how successful Salmon is compared to our existing distribution strategies. If we choose a larger fraction of our bridges to be used for Salmon, it's a good indication that we're finding Salmon to be an effective option. (2a) how often we are reachability-testing each bridge? We'll probably start off doing daily testing, but we should aim to get the frequency higher, and we might end up doing more targeted just-in-time testing where whenever a user reports that a bridge is blocked, we launch a test for it right then in order to make a decision about how to respond to the user. (2b) from how many vantage points we are doing this reachability-testing? We will want to start with n+1 vantage points, one for each target region and one "control" outside the censored area. That might be sufficient for a long time, or we might learn that we need to split up our testing across more vantage points, or test more in particular regions. (2c) how many of our bridges are currently reachable from each of these vantage points? Ideally the answer will be "all of them", but the reality is that some blocking will occur. So the higher the fraction here the better, and in some sense it is a measure of the health of our plans, and/or a measure of the intensity of attention from the censor. (2d) When a bridge stops working in China, what fraction of the time is it because the bridge went down, i.e. normal churn? One of the tradeoffs with a community of volunteer bridges is that bridges naturally come and go over time. Understanding the dynamics of our bridge population is key because it impacts the rate at which users need fresh bridges even when there is no censorship. (3a) how many total users have registered with the salmon system? This long-term measure of how many people have tried to use our system lets us see how well our outreach is working. (3b) how many of those users do we think are recently active? Tracking how many people are still using it is a key indicator for both usability and blocking-resistance: "do people actually find it useful?" (3c) what is the rate of new users registering with the system? First of all this helps us understand growth in interest, for example from our outreach efforts, but also it helps us understand how many fresh bridge addresses we need to support this growth. It is tied into the next item which is the other side of the question: (3d) how many bridges do we have in reserve (not yet filled with users)? The trouble comes when this number reaches 0. So the target is that we always have some bridges in reserve, which means we are keeping up with the rate of new user registrations. If this number hits zero, it means we need to activate more of our partners to get fresh bridges. (4a) how many high-reputation users are currently assigned at least one bridge that we think works? This number summarizes Salmon's success for our high-value or established users. That is, if this number remains high, then Salmon is succeeding at providing availability to its core set of users, even if the other numbers aren't doing well. (4b) how many low-reputation users are currently assigned at least one bridge that we think works? This number measures the other side: what is the health of the Salmon system at adding new users, compared to the attention the censor is giving at adding fake users in order to find and block our bridges? (5a) at what rate are we filling bridges with new salmon users? This one is quite related to 3c above, but it is from the bridge availability side: the best number here is the highest possible number such that 3d doesn't go to 0. (5b) at what rate are we filling bridges with existing salmon users? By looking at the rate where established users need new bridges, we can understand how much stability we have in the system. (5c) at what rate are users reporting failed bridges but we think the bridges are working and reachable for them? This point aims to measure our false positives, which could stem from logic errors inside Tor and Tor Browser (e.g. reporting bridges down when actually our internet isn't on), or from non-uniform blocking within countries, or probably many other reasons. If this rate gets much above 0, it's a bug report that we need to track down and understand. --Roger

1 0

goptlib's git repository, and its (recent) source code
by Vinicius Zavam 27 Sep '20

27 Sep '20

olá Anti-censorship Team, I write to you to share the current status of "goptlib" and its git repositories, plus mirrors (and the source code). As maintainer of "a few" packages depending on goptlib, I missed an updated version of its main git repo (git.tpo/pluggable-transports/goptlib) into the actual GitHub Orga. of the Tor Project (@torproject), or any official mirror like the ones hosted at the new GitLab server - AFAIK, most people relied on @ahf's GitHub sync in the past (also not up to date). - FYI: packages depending on goptlib which were recently ported into *BSD include the OONI Probe CLI So, I took the chance of getting a synced copy into the TorBSD's goptlib repo (github.com/torbsd/goptlib) - which was sadly also with an outdated version of the source code. - I took the already existing repo, and just synced it; did not create or change anything. This move is based on the lack of support of the ports frameworks we currently use on OpenBSD/FreeBSD/NetBSD; they work nicely with GitHub's or GitLab's API, but not with cgit(web). another solution for that would be serving a tarball via https://dist.tpo (but I did not find any). I would be pretty much happy to help and would volunteer myself to keep it always on track, should any extra hands are needed here; but I have a couple questions: - should my GH account be linked to tpo's (@torproject)? - would you like us (TorBSD/tdp) to sign any additional sync or commit? - how oft should we sync (or/and sign)? - is it fine to keep the current updated repo, or would you like us to "deprecate" it? - any other suggestions, ideas or objections? You can reach out to me via email or on IRC (my key+info are on https://tpo/about/people page) That's it... and TYVM for the hard work! Muito obrigado :) KR, -- Vinicius Zavam https://keybase.io/egypcio

2 1

Reading group 2020-10-01: Triplet Censors: Demystifying Great Firewall's DNS Censorship Behavior
by David Fifield 17 Sep '20

17 Sep '20

After the team meeting on 2020-10-01 we will discuss this paper from FOCI 2020: Triplet Censors: Demystifying Great Firewall's DNS Censorship Behavior https://www.usenix.org/conference/foci20/presentation/anonymous

1 0