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

How much traffic is Snowflake sending to stunprotocol.org
by John Selbie 03 Jan '23

03 Jan '23

Greetings, I hope this is an appropriate mailing list to discuss a technical issue with Tor's Snowflake project. Please redirect me to the right place if not. I am the original author and maintainer of the open source project, Stuntman. Stuntman is an implementation of the STUN protocol, which includes the STUN server. More details at www.stunprotocol.org. In short, a STUN server helps bootstream direct "p2p" connections such as WebRTC sessions or similar VOIP scenarios by allowing internet devices to self-discover their own public IP address and obtain a (UDP) port for communicating with another node. I also run a public instance of a STUN server with the code at stun.stunprotocol.org. It's been up and running for about 10 years now. It's hosted on AWS. In recent years, the hosting bills for this server have started to get on the high side, even with reserved instances. The number of STUN queries it processes per day is now on the order of hundreds of millions. The stunprotocol.org domain receives nearly a million DNS queries on Route 53 daily. What used to cost a trivial number of dollars to run is now starting to reach $1000 in annual service costs. This isn't paid for by a corporation or well funded internet organization. I pay this out of my personal pocket. It's been a mystery what has been driving the increasing traffic to the server - especially redundant requests from the same IPs. I was inspecting the DNS logs the other day and started to investigate the nodes sending out redundant DNS requests repetitively. Trying to understand why these nodes wouldn't leverage DNS caching. And to my surprise, one of the IPs was running a web server that presented a TOR landing page. That led me to discover this discussion online: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… And a quick inspection of the Snowflake code leads me to find that stun.stunprotocol.org is the default STUN server for Snowflake proxy and listed throughout the documentation as well. While the Snowflake project has good intentions, it doesn't appear to take my hosting costs into consideration. I'm hoping we can have a good discussion on the following: 1) How many snowflake clients and proxies are active and how many STUN requests are each generating towards stunprotocol.org? Do we think the entire worldwide usage of Snowflake could be responsible for millions of STUN queries to stunprotocol.org per day? 2) Expected number of DNS queries (it's a 3-day TTL on these DNS entries, so it blows my mind that there are so many redundant requests). Does Pion or any other part of the Snowflake code tend to go direct to the namespace server itself? 3) Removing stun.stunprotocol.org as the default STUN server. OR... 4) Alternatively, I'm always open to accepting donations to help run the service costs of stunprotocol.org. I'm definitely not getting rich running this thing. Thanks, John Selbie

4 6

stun.altar.com.pl:3478 no longer functioning?
by David Fifield 30 Dec '22

30 Dec '22

According to OONI stunreachability measurements, stun://stun.altar.com.pl:3478 has been showing 100% anomalies since 2022-10-13. If it's down for good, we ought to remove it from the list of STUN servers. https://explorer.ooni.org/chart/mat?test_name=stunreachability&since=2022-1… Previous mention of stun.altar.com.pl: https://lists.torproject.org/pipermail/anti-censorship-team/2022-May/000237…

1 0

snowflake-01 bridge performance tuning and optimization
by David Fifield 04 Oct '22

04 Oct '22

Linus and I have been putting in a lot of time on the Snowflake bridge over the past week or so to improve performance. The increase in users after the blocking of Tor in Russia last September (the one that led us to the multi-tor architecture) was large, but this recent increase is many times larger. We've cleared out the major bottlenecks and since two days ago days the bridge is finally meeting the additional demand. But it's close: during the busiest times of day the CPU and RAM resources are nearly 100% consumed, and the need for horizontal scaling still exists. There have been a lot of changes, both major and minor. You can find listings at: https://gitlab.torproject.org/tpo/network-health/metrics/timeline/-/blob/f5… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… The most important optimizations have been: - Reduce allocations in WebSocket reads and writes. - Use more than one KCP state machine. - Conserve ephemeral ports in localhost communication. - Disable nftables connection tracking. I attached a graph of bandwidth on the bridge. You can see that between 24 Sep and 02 Oct the daily peaks were unnaturally flattened. The daily shutdowns in Iran caused a paradoxical *increase* in bandwidth, probably because it relieved congestion in the system for the fewer remaining users. In the past two days the shape of the graph looks more natural, and a shutdown decreases bandwidth as you would expect. At its peak, bandwidth is above 4 Gbps. The daily lows are higher than the highest highs of two weeks ago. ## Reduce allocations in writing packets The code forreading and writing encapsulated packets from WebSocket connections was doing unnecessary memory allocations. Some implicit, like a 32 KB buffer being created by io.Copy, and some explicit, like the intentional packet copies being made in the QueuePacketConn type. Reducing allocations makes the garbage collector run less often, and there's also a small benefit from reduced buffer copies. https://gitlab.torproject.org/dcf/snowflake/-/commit/42ea5ff60ce9b3a0dff305… https://gitlab.torproject.org/dcf/snowflake/-/commit/4d4fad30c429bba9062d1b… https://gitlab.torproject.org/dcf/snowflake/-/commit/57c9aa3477513daf433476… ## Use more than one KCP state machine Though most part of snowflake-server are multi-threaded and can scale across many CPUs, the central KCP packet scheduler was limited to one CPU. Because we have a session identity (the client ID) separate from any KCP-specific identity, it's not hard to partition client packets across separate KCP instances by a hash of the client ID. Expanding the number of KCPs from 1 to 2 was enough to relive this bottleneck. https://gitlab.torproject.org/dcf/snowflake/-/commit/17dc8cad8299eae76c4019… ## Conserve ephemeral ports in localhost communication The pluggable transports model relies heavily on localhost TCP sockets. The number of users had increased enough that it was sometimes exhausting the range of port numbers usable for distinct localhost 4-tuples. The kernel's errno for this situation is EADDRNOTAVAIL when you try to connect; it manifests variously in different programs as "cannot assign requested address" or "no free ports," generally leading to a terminated connection. We mitigated this problem by having different programs use different localhost source IP addresses (e.g. 127.0.1.0/24, 127.0.2.0/24, etc.) to expand the space of distinct 4-tuples. In a couple of cases this was done in a hacky way that will need to be revisited, by hardcoding a source address range in the source code. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/dcf/snowflake/-/commit/d8183ff9680ac9f92e888a… https://gitlab.torproject.org/dcf/extor-static-cookie/-/commit/0d9078d6aad8… ## Disable nftables connection tracking We took care of it before it became a problem, but we found it necessary to disable connection tracking in the firewall. The number of tracked connections was getting close to the limit, and past the limit, packets just get dropped. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

1 0

Need to increase number of tor instances on snowflake-01 bridge, increased usage since yesterday
by David Fifield 30 Sep '22

30 Sep '22

There is increased usage of the snowflake-01 bridge since yesterday, likely related to protests/shutdowns in Iran. The 4 load-balanced tor instances, which recently were at about 60% CPU at the steady state, are currently near 100%. I am planning to increase the number of instances today. I am also seeing a lot of "no address in clientID-to-IP map (capacity 10240)" (dozens per second), so I will increase that parameter at the same time. After this, I don't think this bridge can easily sustain another doubling in traffic. It would be good to start sharing load with snowflake-02 sooner than later (https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl…) Here's a bridge-extra-info from a couple of days ago. (Remember this represents 1/4 of traffic.) Here `ir` is in about tenth place in users. https://metrics.torproject.org/collector/recent/bridge-descriptors/extra-in… ``` @type bridge-extra-info 1.3 extra-info flakey1 5481936581E23D2D178105D44DB6915AB06BFB7F published 2022-09-20 13:10:55 write-history 2022-09-20 03:48:24 (86400 s) 1530049041408,1515073429504,1571942788096,1624372588544,1540386311168 read-history 2022-09-20 03:48:24 (86400 s) 1508810912768,1497901086720,1553884182528,1606369537024,1525348965376 dirreq-stats-end 2022-09-20 05:10:35 (86400 s) dirreq-v3-ips ru=13792,us=1864,cn=1240,de=648,gb=384,??=368,by=368,in=280,fr=272,ir=272,ua=224,ca=168,nl=160,br=144,au=136,es=112,it=112,eg=96,sa=80,mx=72,se=72,ro=64,tr=64,ae=56,ch=56,pl=56,be=48,cz=48,jp=48,za=48,at=40,fi=40,id=40,kz=40,lv=40,il=32,kr=32,ph=32,ar=24,az=24,bd=24,cl=24,dk=24,dz=24,ee=24,hk=24,hu=24,ke=24,lt=24,ng=24,no=24,nz=24,pk=24,pt=24,sg=24,th=24,bg=16,co=16,ec=16,gr=16,ie=16,iq=16,ma=16,md=16,mu=16,my=16,si=16,tn=16,tw=16,uz=16,vn=16,af=8,al=8,am=8,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bs=8,bz=8,ci=8,cm=8,cr=8,cu=8,cv=8,cw=8,cy=8,do=8,eu=8,ge=8,gh=8,gn=8,gt=8,hn=8,hr=8,ht=8,is=8,jm=8,jo=8,kg=8,kh=8,kw=8,lb=8,lk=8,lu=8,ly=8,mg=8,mk=8,ml=8,mm=8,mt=8,mv=8,na=8,ne=8,np=8,om=8,pa=8,pe=8,pg=8,ps=8,py=8,qa=8,rs=8,rw=8,sc=8,sd=8,sk=8,sn=8,so=8,sv=8,sy=8,tg=8,tj=8,tm=8,tt=8,tz=8,ug=8,uy=8,ve=8,vi=8,ye=8,zm=8,zw=8 dirreq-v3-reqs ru=25256,??=4032,us=3040,cn=2408,de=1008,gb=616,by=608,fr=472,ua=472,ir=448,in=424,nl=304,ca=296,au=256,br=224,it=200,es=192,eg=136,se=128,mx=120,ro=120,sa=112,ae=88,ch=88,jp=88,pl=88,tr=88,cz=80,lv=80,ph=80,be=72,kr=72,za=72,at=64,fi=64,kz=64,id=56,no=56,ar=48,hk=48,il=40,lb=40,lt=40,pk=40,az=32,bd=32,cl=32,co=32,dk=32,hu=32,ke=32,nz=32,pt=32,sg=32,bg=24,dz=24,ec=24,ee=24,gr=24,mu=24,my=24,ng=24,si=24,so=24,th=24,tw=24,uz=24,am=16,ba=16,bz=16,cm=16,cr=16,hr=16,ie=16,iq=16,jo=16,lk=16,lu=16,ma=16,md=16,mm=16,rs=16,sk=16,tn=16,vn=16,af=8,al=8,ap=8,bf=8,bh=8,bj=8,bn=8,bo=8,bs=8,ci=8,cu=8,cv=8,cw=8,cy=8,do=8,eu=8,ge=8,gh=8,gn=8,gt=8,hn=8,ht=8,is=8,jm=8,kg=8,kh=8,kw=8,ly=8,mg=8,mk=8,ml=8,mt=8,mv=8,na=8,ne=8,np=8,om=8,pa=8,pe=8,pg=8,ps=8,py=8,qa=8,rw=8,sc=8,sd=8,sn=8,sv=8,sy=8,tg=8,tj=8,tm=8,tt=8,tz=8,ug=8,uy=8,ve=8,vi=8,ye=8,zm=8,zw=8 bridge-stats-end 2022-09-20 05:10:44 (86400 s) bridge-ips ru=18816,us=2984,cn=1720,de=1024,gb=640,by=576,??=496,in=488,fr=400,ir=400,ua=280,br=256,nl=256,ca=232,au=192,it=168,eg=160,es=152,sa=128,pl=112,tr=112,mx=104,se=104,ch=96,ro=96,ae=88,jp=80,at=72,be=72,cz=72,id=72,fi=64,kz=56,ph=56,za=56,kr=48,lv=48,az=40,dk=40,il=40,ng=40,no=40,pk=40,ar=32,cl=32,dz=32,gr=32,hk=32,hu=32,ke=32,lt=32,nz=32,pt=32,th=32,bd=24,bg=24,co=24,ee=24,ie=24,ma=24,mu=24,my=24,sg=24,tw=24,uz=24,vn=24,am=16,cr=16,ec=16,hr=16,iq=16,jo=16,kw=16,lk=16,lu=16,md=16,pe=16,py=16,rs=16,sd=16,si=16,sk=16,tm=16,tn=16,ug=16,ve=16,af=8,al=8,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bs=8,bw=8,ci=8,cm=8,cu=8,cv=8,cw=8,cy=8,do=8,et=8,eu=8,ge=8,gh=8,gn=8,gp=8,gt=8,hn=8,ht=8,is=8,jm=8,kg=8,kh=8,ky=8,lb=8,li=8,ly=8,mf=8,mg=8,mk=8,ml=8,mm=8,mq=8,mt=8,mv=8,na=8,ne=8,ni=8,np=8,om=8,pa=8,pg=8,ps=8,qa=8,re=8,rw=8,sc=8,sn=8,so=8,sv=8,sy=8,tg=8,tj=8,tt=8,tz=8,uy=8,vi=8,ye=8,zm=8,zw=8 ``` Here's another bridge-extra-info from about nine hours ago. Now `ir` is in second, third, or fourth place, depending on the metric. ``` @type bridge-extra-info 1.3 extra-info flakey1 5481936581E23D2D178105D44DB6915AB06BFB7F published 2022-09-22 13:18:22 write-history 2022-09-22 03:48:24 (86400 s) 1571942788096,1624372588544,1540386311168,1503769995264,1541499914240 read-history 2022-09-22 03:48:24 (86400 s) 1553884182528,1606369537024,1525348965376,1487172212736,1519574591488 dirreq-stats-end 2022-09-22 05:10:35 (86400 s) dirreq-v3-ips ru=13656,us=2120,ir=2056,cn=1384,de=616,by=432,gb=392,??=384,fr=288,in=264,ua=256,ca=168,nl=168,br=152,au=144,es=112,eg=104,it=104,sa=80,pl=72,se=72,tr=72,ae=64,ch=64,mx=64,ro=64,be=48,cz=48,fi=48,jp=48,za=48,at=40,id=40,kz=40,az=32,cl=32,dk=32,il=32,ke=32,kr=32,lt=32,lv=32,ma=32,ng=32,nz=32,pt=32,co=24,ee=24,gr=24,hk=24,hu=24,mu=24,no=24,ph=24,pk=24,tn=24,ar=16,bd=16,bg=16,do=16,dz=16,ge=16,hr=16,ie=16,iq=16,md=16,my=16,rs=16,sg=16,sk=16,th=16,tw=16,ug=16,uz=16,am=8,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bw=8,ci=8,cm=8,cr=8,cu=8,cv=8,cw=8,cy=8,ec=8,eu=8,ga=8,gh=8,gt=8,gy=8,hn=8,is=8,jm=8,jo=8,kg=8,kh=8,kw=8,ky=8,lb=8,lk=8,lu=8,ly=8,me=8,mk=8,ml=8,mm=8,mo=8,mv=8,mw=8,na=8,ne=8,ni=8,np=8,om=8,pe=8,pr=8,ps=8,py=8,qa=8,re=8,rw=8,sc=8,sd=8,si=8,sn=8,so=8,ss=8,sy=8,tg=8,tm=8,tt=8,tz=8,ve=8,vi=8,vn=8,ye=8,zm=8,zw=8 dirreq-v3-reqs ru=26032,??=4128,us=3408,ir=2792,cn=2784,de=960,by=664,gb=648,ua=592,fr=512,in=360,ca=280,au=272,nl=264,br=248,es=208,it=184,eg=176,mx=152,ae=144,pl=136,ch=128,tr=120,ro=112,se=112,jp=96,sa=96,fi=88,za=80,at=72,be=72,cz=72,il=64,kr=64,kz=64,az=56,dk=56,hu=56,id=56,lt=56,rs=56,hk=48,ke=48,lv=48,cl=40,co=40,ng=40,no=40,nz=40,ph=40,pk=40,pt=40,ee=32,ge=32,gr=32,ma=32,md=32,mu=32,sg=32,tn=32,am=24,ar=24,bd=24,bg=24,dz=24,ie=24,my=24,sk=24,th=24,tw=24,uz=24,cr=16,cy=16,do=16,ec=16,eu=16,hr=16,iq=16,lk=16,ly=16,mm=16,pe=16,si=16,ug=16,vn=16,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bw=8,ci=8,cm=8,cu=8,cv=8,cw=8,ga=8,gh=8,gt=8,gy=8,hn=8,is=8,jm=8,jo=8,kg=8,kh=8,kw=8,ky=8,lb=8,lu=8,me=8,mk=8,ml=8,mo=8,mv=8,mw=8,na=8,ne=8,ni=8,np=8,om=8,pr=8,ps=8,py=8,qa=8,re=8,rw=8,sc=8,sd=8,sn=8,so=8,ss=8,sy=8,tg=8,tm=8,tt=8,tz=8,ve=8,vi=8,ye=8,zm=8,zw=8 bridge-stats-end 2022-09-22 05:10:44 (86400 s) bridge-ips ru=18440,ir=5200,us=3624,cn=1880,de=984,gb=656,by=648,??=520,in=472,fr=416,ua=320,nl=264,br=240,ca=232,au=216,eg=176,it=160,es=152,sa=136,pl=128,se=120,tr=120,ae=104,ch=104,mx=104,ro=96,be=80,jp=80,cz=72,fi=72,id=72,mu=72,za=72,at=64,ng=64,kz=56,ma=56,tn=56,hk=48,il=48,pk=48,az=40,cl=40,co=40,dk=40,dz=40,ke=40,kr=40,lt=40,lv=40,no=40,nz=40,pt=40,ar=32,gr=32,ie=32,my=32,ph=32,sg=32,bd=24,bg=24,ee=24,hu=24,iq=24,rs=24,th=24,tw=24,vn=24,zm=24,cr=16,cy=16,do=16,ec=16,ge=16,gt=16,hr=16,kw=16,lk=16,md=16,mm=16,om=16,pe=16,sd=16,sk=16,tz=16,ug=16,uz=16,ve=16,af=8,al=8,am=8,ao=8,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bw=8,bz=8,ci=8,cm=8,cu=8,cv=8,cw=8,eu=8,ga=8,gh=8,gn=8,gu=8,gy=8,hn=8,is=8,jm=8,jo=8,kg=8,kh=8,ky=8,lb=8,lu=8,ly=8,me=8,mk=8,ml=8,mo=8,mt=8,mv=8,mw=8,na=8,ne=8,ni=8,np=8,pg=8,pr=8,ps=8,py=8,qa=8,re=8,rw=8,sc=8,si=8,sn=8,so=8,sr=8,ss=8,sv=8,sy=8,sz=8,tg=8,tj=8,tm=8,tt=8,uy=8,vi=8,ye=8,zw=8 ```

5 18

Snowflake on OpenWrt
by Daniel Golle 26 Sep '22

26 Sep '22

Hi! I thought it might be good to call your attention to the option of running a Snowflake proxy on small embedded devices, such as home routers. The resulting Go executable takes only about 3.5 MB of flash memory and running it consumes roughly 32 MB of RAM -- resources usually disposable even on consumer-grade home routers. https://github.com/openwrt/packages/pull/19436 I've put each resulting executable into a package of its own, for now providing on init script only for the snowflake-proxy, it runs snowflake as an unpriviledged user/group snowflake:snowflake. In order to make the executables more distinguishable on the target systems I have renamed most of them adding a 'snowflake-' prefix. I'd be glad to hear more opinions and receive review from project developers. Cheers Daniel

2 1

Question about snowflake security
by Luna Manaugh 23 Sep '22

23 Sep '22

Hi there, I don't have a background in programming. Would you care to explain to me in plain language and convincing evidence that it is entirely safe to volunteer for snowflake to help those in heavily censored countries access internet? How's that possible if they can anything with my IP? While I read this on your website, I'm not quite sure I understand what it means: "There is no need to worry about which websites people are accessing through your proxy. Their visible browsing IP address will match their Tor exit node, not yours". Best Luna Sent from Yahoo Mail on Android

2 1

TorCloak Pluggable Transport
by Francisco Silva 06 Sep '22

06 Sep '22

Good evening, My name is Francisco Silva and, together with Professor Nuno Santos and Professor Diogo Barradas, am part of a research team [1] within the Distributed Systems Group at INESC-ID Lisbon [2]/IST [3]. Our research focuses on _systems security and privacy._ We are currently developing a new Tor Pluggable Transport called TorCloak. TorCloak's basic mechanism is to conceale Tor traffic on the video streams of WebRTC-based video conferencing services. We are now coming to a stage on our project in which we are discussing solutions to disseminate our bridges. In the attached file we present a small draft of our proposed solution. This solution is geared towards leveraging the bridge distribution infrastructure already made available by the Tor project and make the process of establishing a bridge connection as simple as possible for the user. We would appreciate your feedback on this solution and, if possible, work with us through the limitations and technicalities of such implementation. Please let us know if you have any questions. You can reach us via email or Matrix. Looking forward to working with you. -- Best regards, Francisco Silva franciscoasilva(a)tecnico.ulisboa.pt @fsilva800:matrix.org web.tecnico.ulisboa.pt/franciscoasilva Links: ------ [1] https://syssec.gsd.inesc-id.pt/ [2] https://inesc-id.pt/ [3] https://tecnico.ulisboa.pt/en/

6 6

Introducing a Conjure PT for Tor
by Cecylia Bocovich 31 Aug '22

31 Aug '22

Conjure[0] is an anti-censorship tool in the refraction networking (a.k.a. decoy routing) lineage of circumvention systems. The key innovation of Conjure is to turn the unused IP address space of deploying ISPs into a large pool of "phantom" proxies that users appear to connect to. Due to the size of unused IPv6 address space and the potential for collateral damage against real websites hosted by the deploying ISPs, Conjure provides a possible solution to the problem of censors enumerating and blocking deployed bridges or proxies. I've been working with Jack Wampler and Eric Wustrow at the University of Colorado to implement a Conjure PT for Tor that uses the existing deployed Conjure stations[1]. # How it works Conjure clients first perform a registration step with the Conjure station to negotiate a phantom IP address to connect through. The idea of a registration phase that precedes the proxied connection is common among anti-censorship tools, including Snowflake. Like Snowflake, there are a few options for making the registration process censorship-resistant. Conjure currently offers unidirectional registration via Tapdance[2] decoy routing, and bidirectional registration via domain fronting. Once the client and station have negotiated a phantom IP address, the client makes a connection to the phantom address. The Conjure station sees this connection and instead proxies traffic using the haproxy[3] protocol to a client-specified destination. Conjure currently supports 3 different transport options for the connection between the client and the phantom proxy: a minimal SSH-based transport, obfs4, and webrtc. The Tor conjure pluggable transport[4] uses the gotapdance library[5] to register and connect to the production Conjure station through the negotiated phantom IP address. We have a deployed Tor bridge (named Haunt) that accepts haproxy connections from an allowlist of known Conjure stations. You can see details and usage metrics on Relay Search: https://metrics.torproject.org/rs.html#details/A84C946BF4E14E63A3C92E140532… # Next steps This PT is currently in development and only recommended for testing. We still have some work to do before the Tor Conjure PT can be rolled out to a large user base. The PT in its current form is very minimal in its features. We're reaching out to the development community now for initial feedback and testing. We are planning a slow ramp of client traffic to avoid placing stress on the stations and improve the reliability and censorship resistance of our setup. Immediate planned work includes: - securing the haproxy connection between the Conjure station and the bridge - making the registration connection censorship resistant - ongoing testing and development of the obfs4 transport integration - usability improvements and resilience in the event of overloaded Conjure stations - reproducible builds for Tor Browser For more details, check out the issue tracker for this project[6]. We have a milestone for shipping conjure support in alpha version of Tor Browser[7], which is the next major step in the rollout process. # Try it out yourself Instructions for cloning and building this PT are in the repository[4]. In the client/ directory there are two provided torrc files. For testing the production Conjure deployment, you may use the one named `torrc`. The other file, `torrc-testing` is for use with the libvirt-based testing and development environment[8]. Successful bootstrapping can take a few tries due to high load at the station. More detailed log messages will be written out to a log file conjure.log by default. This can be changed by modifying the -log argument in the ClientTransportPlugin line of the torrc file. If the station is overloaded, you will see a message like the following in conjure.log: ``` [11:32:12] [1-d9b572] failed to dial phantom [scrubbed]: dial tcp [scrubbed]: i/o timeout ``` Please try it out, open issues, ask questions, provide feedback! # Thanks! Thanks again to Jack and Eric for their efforts on this project, and to whole team of Conjure researchers, developers, and admins for their work on deploying Conjure and making it available for use. [0] https://censorbib.nymity.ch/pdf/Frolov2019b.pdf [1] https://censorbib.nymity.ch/pdf/Frolov2017a.pdf [2] https://censorbib.nymity.ch/pdf/Wustrow2014a.pdf [3] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt [4] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… [5] https://github.com/refraction-networking/gotapdance [6] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… [7] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conj… [8] https://gitlab.torproject.org/cohosh/phantombox

1 0

test gettor reimplementation
by meskio 22 Jul '22

22 Jul '22

Over the last few months we have being working on reimplementing gettor as part of rdsys[0]. As a last step before moving it into production we are testing that everything works fine. You can help us testing it and telling us if everything works as expected or something could be improved by sending emails to it at: gettor-test(a)riseup.net The links provided should work, but they are not located in the official gettor places. You can find the documentation on how to use gettor at: * https://gettor.torproject.org or * https://support.torproject.org/censorship/gettor-2/ * or sending an email with the word help to gettor-test(a)riseup.net Thank you. [0] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/ -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

OONI stunreachability measurements from Russia
by David Fifield 19 May '22

19 May '22

I spent some time looking for the cause of high rates of anomalies in OONI's torsf test: https://explorer.ooni.org/chart/circumvention?since=2022-04-06&until=2022-0… I looked at the recently available (https://github.com/ooni/backend/issues/573) stunreachability measurements, to test whether the Snowflake connections were failing at the STUN phase. In summary, 3 of the pool of 12 STUN servers are inaccessible in Russia. One of them is blocked by censorship in Russia, and the other two look like geoblocking of Russian clients by the STUN service. I don't think the loss of 3 STUN servers is likely to be a cause of many connection failures; therefore I think the explanation lies elsewhere. Here are the charts: https://explorer.ooni.org/chart/mat?probe_cc=RU&test_name=stunreachability&… stun.voip.blackberry.com and the IP address 178.239.90.248 are on the unified register of blocked sites, the entry dated 2017-04-28: https://reestr.rublacklist.net/record/530002/ Here's a measurement showing the test timing out: https://explorer.ooni.org/measurement/20220224T192519Z_stunreachability_RU_… stun.stunprotocol.org is not on the unified register as far as I can tell, nor are its IP addresses 18.191.223.12 and 2600:1f16:8c5:101::108. This domain resolves to 127.0.0.1 or ::1 for requesters located in Russia. Here's a sample measurement: https://explorer.ooni.org/measurement/20220224T111232Z_stunreachability_RU_… Using ooni-sync, we can see that the domain resolves incorrectly only in Russia and Ukraine: $ ./ooni-sync -directory stunreachability test_name=stunreachability since=2022-05-18 until=2022-05-19 $ jq -r 'select(.test_keys.endpoint=="stun.stunprotocol.org:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort ... IT 18.191.223.12 2600:1f16:8c5:101::108 Vodafone Italia S.p.A. IT 18.191.223.12 2600:1f16:8c5:101::108 Vodafone Italia S.p.A. KZ 18.191.223.12 Kar-Tel LLC LK 18.191.223.12 2600:1f16:8c5:101::108 Mobitel Pvt Ltd LT 18.191.223.12 2600:1f16:8c5:101::108 Telia Lietuva, AB MX 18.191.223.12 2600:1f16:8c5:101::108 Mega Cable, S.A. de C.V. MX 18.191.223.12 Mega Cable, S.A. de C.V. NL 18.191.223.12 2600:1f16:8c5:101::108 T-Mobile Thuis BV RU 127.0.0.1 ::1 Cloudflare, Inc. generic_timeout_error RU 127.0.0.1 ::1 Iskratelecom CJSC generic_timeout_error RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error RU 127.0.0.1 ::1 Novotelecom Ltd generic_timeout_error RU 18.191.223.12 PJSC "Bashinformsvyaz" SE 18.191.223.12 2600:1f16:8c5:101::108 Telia Company AB SE 18.191.223.12 Vetenskapsradet / SUNET SG 18.191.223.12 2600:1f16:8c5:101::108 Leaseweb Asia Pacific pte. ltd. TW 18.191.223.12 2600:1f16:8c5:101::108 <unknown> TW 18.191.223.12 2600:1f16:8c5:101::108 <unknown> UA 127.0.0.1 ::1 Virtual Systems LLC generic_timeout_error US 18.191.223.12 2600:1f16:8c5:101::108 AT&T Services, Inc. US 18.191.223.12 2600:1f16:8c5:101::108 AT&T Services, Inc. US 18.191.223.12 2600:1f16:8c5:101::108 CABLE ONE, INC. ... stun.altar.com.pl is not on the unified register, nor is its IP address 176.119.42.11. Its failures only start on 2022-03-09. Its domain usually resolves correctly, but in Russia the actual STUN phase usually results in a timeout: $ jq -r 'select(.test_keys.endpoint=="stun.altar.com.pl:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort | grep RU RU 176.119.42.11 Cloudflare, Inc. RU 176.119.42.11 Iskratelecom CJSC generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 Novotelecom Ltd generic_timeout_error RU 176.119.42.11 PJSC "Bashinformsvyaz" generic_timeout_error But there are also errors for networks in Spain, Hong Kong, Indonesia, and the United States: $ jq -r 'select(.test_keys.endpoint=="stun.altar.com.pl:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort | grep error ES 176.119.42.11 Orange Espagne SA generic_timeout_error HK Hong Kong University of Science and Technology generic_timeout_error ID Telekomunikasi Indonesia (PT) generic_timeout_error RU 176.119.42.11 Iskratelecom CJSC generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 Novotelecom Ltd generic_timeout_error RU 176.119.42.11 PJSC "Bashinformsvyaz" generic_timeout_error US 176.119.42.11 2607:7700:0:18::b077:2a0b T-Mobile USA, Inc. generic_timeout_error US 176.119.42.11 2607:7700:0:1f:0:1:b077:2a0b T-Mobile USA, Inc. generic_timeout_error US 176.119.42.11 2607:7700:0:7::b077:2a0b T-Mobile USA, Inc. generic_timeout_error US 176.119.42.11 T-Mobile USA, Inc. generic_timeout_error US 176.119.42.11 T-Mobile USA, Inc. generic_timeout_error To me this looks like selective denial of service to certain client networks. Last weeks discussion on this topic: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-05-12-15.58.log…

1 0