December 2024 - tor-project - lists.torproject.org

Are there countries where using Tor is illegal?
by Cristian Consonni 11 May '25

11 May '25

Hi, (Sorry if this question has already been asked in the past, feel free to point me to the relevant resources.) I know that the legal FAQs by the EFF state that: «we believe that running a Tor relay — including an exit relay that allows people to anonymously send and receive traffic — is legal under U.S. law.»[1] I also know there is a list of countries for which there is legislation that exclude communication service providers from liability. They are indicated in the Legal of the Tor Exit Guidelines page[2], they are USA, Germany, Netherlands, Austria, France, and Sweden. >From some articles in the press[3a][3b] it may be illegal - depending on how you interpret the wording[*] - to use Tor (and other technologies such as VPNs or proxies) in the UAE, with fines ranging in the millions of dirhams (hundreds of thousand of dollars). A couple of weeks ago it was discussed - on this list as well - that a law was introduced to the state parliament to ban Tor[4a][4b]. This follows a case of some months ago of a Russian Tor exit node operator being arrested for inciting mass riots and terrorism[4c][4d]. The idea of blocking VPNs or Tor seems to have already been considered in the past[4e]. This infographic about pluggable transports[5] suggests access to the Tor network is censored or limited in China, Uzbekistan, Iran, and Kazakhstan. Tor being censored orblocked may be different from it being illegal. What about other countries? Is there a place where I can find more about this topic? Cristian [1]: https://www.torproject.org/eff/tor-legal-faq.html.en [2]: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines [3a]: http://www.emirates247.com/news/emirates/dh500-000-fine-if-you-use-fraud-ip… [3b]: http://news.softpedia.com/news/people-caught-using-vpns-tor-or-proxies-in-t… [*]: «Whoever uses a fraudulent computer network protocol address (IP address) by using a false address or a third-party address by any other means for the purpose of committing a crime or preventing its discovery» [4a]: https://lists.torproject.org/pipermail/tor-talk/2017-June/043293.html [4b]: https://trac.torproject.org/projects/tor/ticket/22055 [4c]: https://lists.torproject.org/pipermail/tor-talk/2017-April/043109.html [4d]: https://techcrunch.com/2017/04/24/dmitry-bogatov-tor-russia/ [4e]; https://torrentfreak.com/vpn-and-tor-ban-looming-on-the-horizon-for-russia-… [5]: https://www.torproject.org/images/PT/2016-07-how-to-use-PT.png

4 3

TPA-RFC-71: Emergency email deployments, phase B
by Antoine Beaupré 26 Mar '25

26 Mar '25

Hi, So TPA has adopted this proposal, internally, to make yet another set of emergency changes to our mail system, to respond to critical issues affecting delivery and sustainability of our infrastructure. I encourage you to read the "Affected users" section and "Timeline" below. In particular, we will be experimenting with "sender rewriting" soon, which will involve mangling emails we forward around to try and fix deliverability on those. The schleuder mailing list will also move servers. Maintenance windows for those changes will be communicated separately. Thank you for your attention! PS: and no, we didn't submit this for adoption to everyone, because it was felt it was mostly technical changes that didn't warrant outside approval, let me know if that doesn't make sense, of course. -- Antoine Beaupré torproject.org system administration --- title: TPA-RFC-71: Emergency email deployments, phase B costs: staff approval: TPA affected users: all torproject.org email users deadline: 5 days, 2024-10-01 status: draft discussion: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41778 --- Summary: deploy a new sender-rewriting mail forwarder ASAP, migrate mailing lists off the legacy server to a new machine, migrate the remaining Schleuder list to the Tails server, upgrade `eugeni`. Table of contents: - Background - Proposal - Actual changes - Mailman 3 upgrade - New sender-rewriting mail exchanger - Schleuder migration - Upgrade legacy mail server - Goals - Must have - Nice to have - Non-Goals - Scope - Affected users - Personas - Timeline - Optimistic timeline - Worst case scenario - Alternatives considered - References - History - Personas descriptions - Ariel, the fundraiser - Blipblop, the bot - Gary, the support guy - John, the contractor - Mallory, the director - Nancy, the fancy sysadmin - Orpheus, the developer # Background In [#41773][], we had yet another report of issues with mail delivery, particularly with email forwards, that are plaguing Gmail-backed aliases like grants@ and travel@. [#41773]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41773 This is becoming critical. It has been impeding people's capacity of using their email at work for a while, but it's been more acute since google's recent changes in email validation (see [#41399][]) as now hosts that have adopted the SPF/DKIM rules are bouncing. [#41399]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41399 On top of that, we're way behind on our buster upgrade schedule. We still have to upgrade our primary mail server, `eugeni`. The plan for that ([TPA-RFC-45][], [#41009][]) was to basically re-architecture everything. That won't happen fast enough for the LTS retirement which we have crossed two months ago (in July 2024) already. [TPA-RFC-45]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-45-mail-a… [#41009]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41009 So, in essence, our main mail server is unsupported now, and we need to fix this as soon as possible Finally, we also have problems with certain servers (e.g. `state.gov`) that seem to dislike our bespoke certificate authority (CA) which makes *receiving* mails difficult for us. # Proposal So those are the main problems to fix: - Email forwarding is broken - Email reception is unreliable over TLS for some servers - Mail server is out of date and hard to upgrade (mostly because of Mailman) ## Actual changes The proposed solution is: - **Mailman 3 upgrade** ([#40471][]) - **New sender-rewriting mail exchanger** ([#40987][]) - **Schleuder migration** - **Upgrade legacy mail server** ([#40694][]) [#40471]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40471 [#40987]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40987 [#40694]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40694 ### Mailman 3 upgrade Build a new mailing list server to host the upgraded Mailman 3 service. Move old lists over and convert them while retaining the old archives available for posterity. This includes lots of URL changes and user-visible disruption, little can be done to work around that necessary change. We'll do our best to come up with redirections and rewrite rules, but ultimately this is a disruptive change. This involves yet another authentication system being rolled out, as Mailman 3 has its own user database, just like Mailman 2. At least it's one user per site, instead of per list, so it's a slight improvement. This is issue [#40471][]. ### New sender-rewriting mail exchanger This step is carried over from [TPA-RFC-45][], mostly unchanged. [Sender Rewriting Scheme]: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme [postsrsd]: https://github.com/roehling/postsrsd [postforward]: https://github.com/zoni/postforward Configure a new "mail exchanger" (MX) server with TLS certificates signed by our normal public CA (Let's Encrypt). This replaces that part of `eugeni`, will hopefully resolve issues with `state.gov` and others ([#41073][], [#41287][], [#40202][], [#33413][]). [#33413]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33413 [#40202]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40202 [#41287]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41287 [#41073]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41073 This would handle forwarding mail to other services (e.g. mailing lists) but also end-users. To work around reputation problems with forwards ([#40632][], [#41524][], [#41773][]), deploy a [Sender Rewriting Scheme][] (SRS) with [postsrsd][] (packaged in Debian, but [not in the best shape][]) and [postforward][] (not packaged in Debian, but zero-dependency Golang program). It's possible deploying [ARC][] headers with [OpenARC][], Fastmail's [authentication milter][] (which [apparently works better][]), or [rspamd's arc module][] might be sufficient as well, to be tested. [OpenARC]: https://tracker.debian.org/pkg/openarc [not in the best shape]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017361 Having it on a separate mail exchanger will make it easier to swap in and out of the infrastructure if problems would occur. The mail exchangers should also sign outgoing mail with DKIM, and *may* start doing better validation of incoming mail. [authentication milter]: https://github.com/fastmail/authentication_milter [apparently works better]: https://old.reddit.com/r/postfix/comments/17bbhd2/about_arc/k5iluvn/ [rspamd's arc module]: https://rspamd.com/doc/modules/arc.html [#41524]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41524 [#40632]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40632 [ARC]: http://arc-spec.org/ ### Schleuder migration Migrate the remaining mailing list left (the Community Council) to the Tails Shleuder server, retiring our Schleuder server entirely. This requires configuring the Tails server to accept mail for `(a)torproject.org`. Note that this may require changing the addresses of the existing Tails list to `(a)torproject.org` if Schleuder doesn't support virtual hosting (which is likely). ### Upgrade legacy mail server Once Mailman has been safely moved aside and is shown to be working correctly, upgrade Eugeni using the normal procedures. This should be a less disruptive upgrade, but is still risky because it's such an old box with lots of legacy. One key idea of this proposal is to keep the legacy mail server, `eugeni`, in place. It will continue handling the "MTA" (Mail Transfer Agent) work, which is to relay mail for other hosts, as a legacy system. The full eugeni replacement is seen as too complicated and unnecessary at this stage. The legacy server will be isolated from the rewriting forwarder so that outgoing mail is mostly unaffected by the forwarding changes. ## Goals This is not an exhaustive solution to all our email problems, [TPA-RFC-45][] is that longer-term project. ### Must have - Up to date, supported infrastructure. - Functional legacy email forwarding. ### Nice to have - Improve email forward deliverability to Gmail. ### Non-Goals - **Clean email forwarding**: email forwards *may* be mangled and rewritten to appear as coming from `(a)torproject.org` instead of the original address. This will be figured out at the implementation stage. - **Mailbox storage**: out of scope, see [TPA-RFC-45][]. It is hoped, however, that we *eventually* are able to provide such a service, as the sender-rewriting stuff might be too disruptive in the long run. - **Technical debt**: we keep the legacy mail server, `eugeni`. - **Improved monitoring**: we won't have a better view in how well we can deliver email. - **High availability**: the new servers will not add additional "single point of failures", but will not improve our availability situation (issue [#40604][]) [#40604]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40604 ## Scope This proposal affects the all inbound and outbound email services hosted under `torproject.org`. Services hosted under `torproject.net` are *not* affected. It also does *not* address directly phishing and scamming attacks ([#40596][]), but it is hoped the new mail exchanger will provide a place where it is easier to make such improvements in the future. [#40596]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40596 ## Affected users This affects all users which interact with `torproject.org` and its subdomains over email. It particularly affects all "tor-internal" users, users with LDAP accounts, or forwards under `(a)torproject.org`, as their mails will get rewritten on the way out. ### Personas Here we collect a few "personas" and try to see how the changes will affect them, largely derived from [TPA-RFC-45][], but without the alpha/beta/prod test groups. For *all* users, a common impact is that emails will be rewritten by the sender rewriting system. As mentioned above, the impact of this still remains to be clarified, but at least the hidden `Return-Path` header will be changed for bounces to go to our servers. Actual personas are in the Reference section, see [Personas descriptions][]. | Persona | Task | Impact | |---------|-------------|--------------------------------------------------------------------------| | Ariel | Fundraising | Improved incoming delivery | | Blipbot | Bot | No change | | Gary | Support | Improved incoming delivery, new moderator account on mailing list server | | John | Contractor | Improved incoming delivery | | Mallory | Director | Same as Ariel | | Nancy | Sysadmin | No change in delivery, new moderator account on mailing list server | | Orpheus | Developer | No change in delivery | [Personas descriptions]: #personas-descriptions ## Timeline ### Optimistic timeline - Late September (W39): issue raised again, proposal drafted (now) - October: - W40: proposal approved, installing new rewriting server - W41: rewriting server deployment, new mailman 3 server - W42: mailman 3 mailing list conversion tests, users required for testing - W43: mailman 2 retirement, mailman 3 in production - W44: Schleuder mailing list migration - November: - W45: `eugeni` upgrade ### Worst case scenario - Late September (W39): issue raised again, proposal drafted (now) - October: - W40: proposal approved, installing new rewriting server - W41-44: difficult rewriting server deployment - November: - W44-W48: difficult mailman 3 mailing list conversion and testing - December: - W49: Schleuder mailing list migration vetoed, Schleuder stays on `eugeni` - W50-W51: `eugeni` upgrade postponed to 2025 - January 2025: - W3: `eugeni` upgrade # Alternatives considered We decided to not just run the sender-rewriting on the legacy mail server because too many things are tangled up in that server. It is just too risky. We have also decided to not upgrade Mailman in place for the same reason: it's seen as too risky as well, because we'd first need to upgrade the Debian base system and if that fails, rolling back is too hard. # References - [discussion issue][] [discussion issue]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41778 ## History This is the the *fifth* proposal about our email services, here are the previous ones: * [TPA-RFC-15: Email services][] (rejected, replaced with TPA-RFC-31) * [TPA-RFC-31: outsource email services][] (rejected, in favor of TPA-RFC-44 and following) * [TPA-RFC-44: Email emergency recovery, phase A][] (standard, and mostly implemented except the sender-rewriting) * [TPA-RFC-45: Mail architecture][] (still draft) [TPA-RFC-15: Email services]: policy/tpa-rfc-15-email-services [TPA-RFC-31: outsource email services]: policy/tpa-rfc-31-outsource-email [TPA-RFC-44: Email emergency recovery, phase A]: policy/tpa-rfc-44-email-emergency-recovery [TPA-RFC-45: Mail architecture]: policy/tpa-rfc-45-mail-architecture ## Personas descriptions ### Ariel, the fundraiser Ariel does a lot of mailing. From talking to fundraisers through their normal inbox to doing mass newsletters to thousands of people on CiviCRM, they get a lot done and make sure we have bread on the table at the end of the month. They're awesome and we want to make them happy. Email is absolutely mission critical for them. Sometimes email gets lost and that's a major problem. They frequently tell partners their personal Gmail account address to work around those problems. Sometimes they send individual emails through CiviCRM because it doesn't work through Gmail! Their email forwards to Google Mail and they now have an LDAP account to do email delivery. ### Blipblop, the bot Blipblop is not a real human being, it's a program that receives mails and acts on them. It can send you a list of bridges (bridgedb), or a copy of the Tor program (gettor), when requested. It has a brother bot called Nagios/Icinga who also sends unsolicited mail when things fail. There are also bots that sends email when commits get pushed to some secret git repositories. ### Gary, the support guy Gary is the ticket overlord. He eats tickets for breakfast, then files 10 more before coffee. A hundred tickets is just a normal day at the office. Tickets come in through email, RT, Discourse, Telegram, Snapchat and soon, TikTok dances. Email is absolutely mission critical, but some days he wishes there could be slightly less of it. He deals with a lot of spam, and surely something could be done about that. His mail forwards to Riseup and he reads his mail over Thunderbird and sometimes webmail. Some time after TPA-RFC_44, Gary managed to finally get an OpenPGP key setup and TPA made him a LDAP account so he can use the submission server. He has already abandoned the Riseup webmail for TPO-related email, since it cannot relay mail through the submission server. ### John, the contractor John is a freelance contractor that's really into privacy. He runs his own relays with some cools hacks on Amazon, automatically deployed with Terraform. He typically run his own infra in the cloud, but for email he just got tired of fighting and moved his stuff to Microsoft's Office 365 and Outlook. Email is important, but not absolutely mission critical. The submission server doesn't currently work because Outlook doesn't allow you to add just an SMTP server. John does have an LDAP account, however. ### Mallory, the director Mallory also does a lot of mailing. She's on about a dozen aliases and mailing lists from accounting to HR and other unfathomable things. She also deals with funders, job applicants, contractors, volunteers, and staff. Email is absolutely mission critical for her. She often fails to contact funders and critical partners because `state.gov` blocks our email -- or we block theirs! Sometimes, she gets told through LinkedIn that a job application failed, because mail bounced at Gmail. She has an LDAP account and it forwards to Gmail. She uses Apple Mail to read their mail. ### Nancy, the fancy sysadmin Nancy has all the elite skills in the world. She can configure a Postfix server with her left hand while her right hand writes the Puppet manifest for the Dovecot authentication backend. She browses her mail through a UUCP over SSH tunnel using mutt. She runs her own mail server in her basement since 1996. Email is a pain in the back and she kind of hates it, but she still believes entitled to run their own mail server. Her email is, of course, hosted on her own mail server, and she has an LDAP account. She has already reconfigured her Postfix server to relay mail through the submission servers. ### Orpheus, the developer Orpheus doesn't particular like or dislike email, but sometimes has to use it to talk to people instead of compilers. They sometimes have to talk to funders (`#grantlyfe`), external researchers, teammates or other teams, and that often happens over email. Sometimes email is used to get important things like ticket updates from GitLab or security disclosures from third parties. They have an LDAP account and it forwards to their self-hosted mail server on a OVH virtual machine. They have already reconfigured their mail server to relay mail over SSH through the jump host, to the surprise of the TPA team. Email is not mission critical, and it's kind of nice when it goes down because they can get in the zone, but it should really be working eventually. -- Antoine Beaupré torproject.org system administration -- tpa-team mailing list tpa-team(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tpa-team

2 10

sajolida's report, September 2024
by sajolida 27 Feb '25

27 Feb '25

Hi, September was again more busy than average to respect the timeline of Project 101 (Tor VPN) and Tails releases. Tor VPN ======= - I analyzed the usability test of Tor VPN 0.6.2 that I did in August. https://gitlab.torproject.org/tpo/ux/research/-/issues/69 In short, the usability of Tor VPN 0.6.2 is decent when people don't need to use a bridge, but very bad when Tor is blocked. None of the participant managed to use a bridge on their own. The main issues are unclear system status and confusing network model. Quotes: “Tor is like a bridge.“ — P5 “I'm looking for bridges that make it like if I were in Switzerland.“ — P4 “It should say: You are being blocked! With Tor you can bypass this censorship using a bridge.“ — P6 Summary of findings: https://gitlab.torproject.org/-/project/92/uploads/1fba8220a110622d852bf448… List of all issues: https://nc.torproject.net/s/fXbRYw76pTXJZym Video clips: https://nc.torproject.net/f/645757 - I created GitLab issues to document the most severe issues: Improve feedback while "Connecting" https://gitlab.torproject.org/tpo/applications/vpn/-/issues/181 Clarify connection status on all screens https://gitlab.torproject.org/tpo/applications/vpn/-/issues/182 Allow changing exit location from Configure menu https://gitlab.torproject.org/tpo/applications/vpn/-/issues/185 Improve discoverability of the list of countries https://gitlab.torproject.org/tpo/applications/vpn/-/issues/186 Clarify what can be tapped in the Bridges screen https://gitlab.torproject.org/tpo/applications/vpn/-/issues/187 Remove the need to press Enter when entering a bridge line https://gitlab.torproject.org/tpo/applications/vpn/-/issues/188 Clarify which bridge is being used (eg. after Bridge Bot) https://gitlab.torproject.org/tpo/applications/vpn/-/issues/189 Improve discoverability of the circuit view https://gitlab.torproject.org/tpo/applications/vpn/-/issues/190 Allow configuring only a single bridge https://gitlab.torproject.org/tpo/applications/vpn/-/issues/193 Rethink how the different relays are named https://gitlab.torproject.org/tpo/applications/vpn/-/issues/194 Clarify just enough about the network model https://gitlab.torproject.org/tpo/applications/vpn/-/issues/195 Don't allow changing exit location unless already connected https://gitlab.torproject.org/tpo/applications/vpn/-/issues/196 Report loss of connectivity to the Tor network https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/110 - I started brainstorming solutions to all of these issues with Duncan and the rest of the UX team. Tails ===== I wrote some documentation to help users with recent issues: - Shim SBAT verification error (#20471) https://tails.net/news/version_6.7/#sbat - Provide fsck from Welcome Screen when the file system of the Persistent Storage is corrupted (#15451) https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1586 This one was a LOT of work to figure out which data forensics path we should recommend to users and document the main ones step-by-step. -- sajolida

1 5

getting ready for TPA holidays
by Antoine Beaupré 20 Dec '24

20 Dec '24

Hi, So it's the most wonderful time of the year and everything... This means that we're actually coming pretty close to the holidays! TL;DR: everything will be fine, but if you need something from us before the holidays, ask now! TPA is, as usual, going to ensure some minimal rotation during the TPI holidays (December 21st to January 5th, inclusively), so we should be able to deal with emergencies. We'll have someone checking alerts and mail on a daily basis, basically. "How to report issues" doesn't change, see: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/support If you're curious, you can see who's on rotation in the "TPA rotations" calendar I have just shared with TPI (an oversight). That said. If you think you might need something urgently before the holidays, it's getting *really* late to tell us now, as we're pretty much trying to wrap up everything to quiet down our infra before the holidays. So if you need anything from TPA, the time to ask for this is pretty much right now, we'll be glad to consider your request! And as the ~3 weeks pass before the holidays, we'll be less and less happy to deal with urgent "oh I just need this blog post" or "can I get a little VM cluster setup now?" right before the holidays. :) (If you need a coordinated release right before the holidays, that's fine too, but let's plan it no!) Thank you for your attention, and happy holidays! a. -- Antoine Beaupré torproject.org system administration

1 1

Tor Browser Meeting rescheduling
by Morgan 19 Dec '24

19 Dec '24

Hello everyone! Daylight savings has migrated the weekly Tor Browser meeting to an unreasonable hour for some of us, so lets move it back an hour to 1600 UTC in #tor-meeting2 in 2025. best, -morgan

1 1

Anti-censorship team meeting notes, 2024-12-19
by meskio 19 Dec '24

19 Dec '24

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-12-19-16.00.html And our meeting pad: Anti-censorship -------------------------------- Next meeting: Thursday,January 9 16:00 UTC Facilitator: onyinyang ^^^(See Facilitator Queue at tail) Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: meskio == Goal of this meeting == Weekly check-in about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at the Tor Project and Tor community. == 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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * Azure CDN from Edgio (azureedge.net) is due to be shut down as early as 2025-01-15: https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * We stopped using snowflake-broker.azureedge.net in 2021: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… * But it still receives traffic somehow: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… * onionwrapper still uses snowflake-broker.azureedge.net: https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * (also, anything still using snowflake-broker.azureedge.net is using the old broker not working right now, see discussion below) * No meetings during the next two weeks. Next meeting: January 9th == Discussion == * Azure CDN from Edgio shutdown * Might make our meek builtin bridge stop working, requiring a change or removal as a default option * cohosh will follow up with micah * added a CDN77 meek bridge to the builtin bridges * going to change azure to ampcache, or sqs for China * https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_reque… * alternative domain names for CDN77 domain front * we are using phpmyadmin.net as domian front for snowflake, meek and moat * should we diversify? * https://forum.torproject.org/t/tor-and-hetzner-block-in-russia/16134/3 * tiktok domains? * in China there is a domestic version called douyin, tiktok itself may not be accessible? * shelikhoo will add support for testing domainfronts in vantage points to see what works where * snowflake-broker.azureedge.net (Edgio) became broken after being changed to point to snowflake-broker.torproject.net (the newly set up broker), because of some TLS certificate verification error between the CDN server and the broker origin. * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * The suspicion is that the Edgio CDN server is, for some reason, sending a incorrect SNI ("snowflake-broker.bamsoftware.com"; i.e., the old broker, which is how it was initially set up), even though all visible configuration options have been changed to say "snowflake-broker.torproject.net" instead. * Sample SNIs reaching the broker to see if snowflake-broker.bamsoftware.com is among them? * tshark -i eth0 -f 'dst port 443' -Y 'ssl.handshake.extension.type == "server_name"' -T fields -e tls.handshake.extensions_server_name * If so, then we could point the DNS record for snowflake-broker.bamsoftware.com at the new broker, and let the new broker generate certificates for that name, for as long as the Edgio CDN still holds out. * dcf will run the tshark command and report in #40427 * covert-dtls in snowflake client and standalone proxy -- is there a plan for volunteer testing before merging? * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * the recent partial blocking in Russia has ended, so asking for user testing there won't reveal whether the changed fingerprint makes a difference * but it still could be valuable to have users run with the patch as a kind of integration and interoperability test * need to test both standalone proxy and client * meskio can try running the patch on a standalone proxy * (but there's no way to get per-country statistics) * covert-dtls should be tested in both modes: randomize and mimic * theodorsm will produce instructions on how to compile and test the client with the help of cohosh * and nina will translate to post it in ntc.party == Actions == == Interesting links == * https://dl.acm.org/doi/10.1145/3589334.3645656 * Discovering and Measuring CDNs Prone to Domain Fronting (2024, open access) * https://ieeexplore.ieee.org/document/10190674 * Assessing and Exploiting Domain Name Misinformation (2023, not open access) == Reading group == * We will discuss "Discovering and Measuring CDNs Prone to Domain Fronting" on January 16th * https://dl.acm.org/doi/10.1145/3589334.3645656 * 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. cecylia (cohosh): 2024-12-19 Last week: - gitlab reviews and todos - more work on snowflake broker metrics improvements - handled meek builtin bridge update and azure edge shutdown This week: - afk for a few weeks dcf: 2024-12-19 Last week: - worked on making the Edgio CDN snowflake-broker.azureedge.net point to the new broker, but ran into problems with TLS certificate verification https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… - opened an issue for an error in the Snowflake Broker Survival Guide: the documented way to read the broker logs doesn't work https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - opened an issue to clean up the way multiple server names are handled on the snowflake broker https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - archived snowflake-webextension 0.9.0 and 0.9.2 https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… https://archive.org/details/snowflake-webextension-0.9.0 https://archive.org/details/snowflake-webextension-0.9.2 - answered questions from a student interested in experimenting with media streams in snowflake Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2024-12-19 Last week: - grant writting world - catching up with things from and after SplinterCon Next week: - winter break Shelikhoo: 2024-12-19 Last Week: - [Pending] snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Merge request reviews - Analysis Iran vantage point result Next Week/TODO: - Merge request reviews - [Resume] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Analysis Iran vantage point result onyinyang: 2024-12-19 Last week(s): - Deployed test distributor - endpoints are available @ lox-test.torproject.org - Updated lox protocols to return duplicate responses for an already seen request Next week: - Break - Continue work on implementing issuer efficiency for check-blockage and trust-promotion protocols - Work on outstanding milestone issues: - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096) - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by PT, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less? theodorsm: 2024-12-19 Last weeks: - WIP MR: Add covert-dtls to proxy and client - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next weeks: - Fix merge conflicts in MR. - Write instructions on how to configure covert-dtls with snowflake client - Condensing thesis into paper (on hold) Help with: - Test stability of covert-dtls in snowflake MR Facilitator Queue: meskio onyinyang shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

Felicia's Montly Status Report, December 2024
by Priscila 19 Dec '24

19 Dec '24

Hi everyone, I’m sending my report for December earlier since the holiday break is right at the corner. So, this month I continued working on making the need of a Moat call during connect assist more clear for users [1]. This issue is currently on review, so there’s a possibility I need to adjust something more next month. Besides that, I’ve also been working on improving the UX of the “Request bridges”flow [2], which is related to the following issues: [3] Remove the CAPTCHA from the “Request bridges” flow and [4] improve the confirmation step of the “Add new bridges” dialog. These issues are on review as well, so they’ll probably be completed next month. Lastly, I provided assistance to devs in an issue related to bootstrapping and Settings when the Tor daemon isn’t ready yet [5]. This issue branched out into 2, being the other one focused on reviewing the error prompt shown when Tor exists [6]. That’s all for now. Happy holidays! Best, Priscila (aka Felicia) - UX Team - [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42605 [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41620 [3] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42086 [4] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42692 [5] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41921 [6] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43186

1 0

Rhatto's Monthly Status Report, December 2024
by rhatto 18 Dec '24

18 Dec '24

Hi all :) This is my monthly status report for December 2024 with the main relevant activities I have done, was involved or are related to my work during the period. I'm sending this in advance due to the holiday break. Focus for this month was Ansible role development. ## Ansible Roles * Onionprobe Ansible role: * Released versions 0.0.2 to 0.0.6: https://gitlab.torproject.org/tpo/onion-services/ansible/onionprobe-role * Onionspray Ansible Role: * We adopted Yassine Zouggari's role, which is now hosted at https://gitlab.torproject.org/tpo/onion-services/ansible/onionspray-role * The next release is being planned: https://gitlab.torproject.org/tpo/onion-services/ansible/onionspray-role/-/… * Auxiliar roles: * Released a very simple Docker Ansible role: https://gitlab.torproject.org/tpo/onion-services/ansible/docker-role * A role for basic system setup is also available: https://gitlab.torproject.org/tpo/onion-services/ansible/basic-role * These can be useful, but there's no guarantees that they'll be maintained in the long run, as they mostly contain auxiliary system tasks. ## Other releases * Onion Launchpad 1.0.2 (a landing page for onionsites): https://onionservices.torproject.org/apps/web/onion-launchpad/changelog/#v1… * Onionbalance 0.2.3 (load balancer for Onion Services): https://forum.torproject.org/t/onionbalance-release-0-2-3/16287 * Onionspray 1.6.2 (application to serve regular websites as onionsites): https://forum.torproject.org/t/onionspray-release-1-6-2/16014 * Onionprobe 1.2.2 (an Onion Services monitoring tool): https://forum.torproject.org/t/onionprobe-release-1-2-1/16015 ## Support Did the ongoing sponsored work with deployment, maintenance and monitoring of Onion Services. -- Silvio Rhatto pronouns he/him

1 0

TPA-RFC-74: GitLab CI retention policy
by Jérôme Charaoui 16 Dec '24

16 Dec '24

Summary: a proposal to limit the retention of GitLab CI data to 1 year # Background As more and more Tor projects moved to GitLab and embraced its continuous integration features, managing the ensuing storage requirements has been a challenge. We regularly deal with near filesystem saturation incidents on the GitLab server, especially involving CI artifact storage, such as tpo/tpa/team#41402 and recently, tpo/tpa/team#41861 Previously, [TPA-RFC-14][] was implemented to reduce the default artifact retention period from 30 to 14 days. This, and CI optimization of individual projects has provided relief, but the long-term issue has not been definitively addressed since the retention period doesn't apply to some artifacts such as job logs, which are kept indefinitely by default. [TPA-RFC-14]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/tpa-rfc-14-gitlab-artifa… # Proposal Implement a daily GitLab maintenance task to delete CI pipelines older than 1 year in *all* projects hosted on our instance. This will: * Purge old CI pipeline and job records for the GitLab database * Delete associated CI job artifacts, even those "kept" either: * When [manually prevented from expiring][] ("Keep" button on CI job pages) * When they're the [latest successful pipeline artifact][] * Delete old CI job log artifacts [manually prevented from expiring]: https://gitlab.torproject.org/help/ci/jobs/job_artifacts#with-an-expiry [latest successful pipeline artifact]: https://gitlab.torproject.org/help/ci/jobs/job_artifacts.md#keep-artifacts-… ## Goals This is expected to significantly reduce the growth rate of CI-related storage usage, and of the GitLab service in general. ## Affected users All users of GitLab CI will be impacted by this change. But more specifically, some projects have "kept" artifacts, which were manually set not to expire. We'll ensure the concerned users and projects will be notified of this proposal. GitLab's documentation has the [instructions to extract this list of non-expiring artifacts](https://docs.gitlab.com/ee/administration/cicd/job_artifacts_tro…. ## Timeline Barring the need to further discussion, this will be implemented on Monday, December 9th. ## Costs estimates ### Hardware This is expected to reduce future requirements in terms of storage hardware. ### Staff This will reduce the amount of TPA labor needed to deal with filesystem saturation incidents. # Alternatives considered A "CI housekeeping" script is already in place, which scrubs job logs daily in a hard-coded list of key projects such as c-tor packaging, which runs an elaborate CI pipeline on a daily basis, and triage-bot, which runs it CI pipeline on a schedule, every 15 minutes. Although it has helped up until now, this approach is not able to deal with the increasing use of personal fork projects which are used for development. It's possible to define a different retention policy based on a project's namespace. For example, projects under the `tpo` namespace could have a longer retention period, while others (personal projects) could have a shorter one. This isn't part of the proposal currently as it could violate the principle of least surprise. # References * Discussion ticket: tpo/tpa/team#41874 * [Make It Ephemeral: Software Should Decay and Lose Data](https://lucumr.pocoo.org/2024/10/30/make-it-ephemeral/)

1 1

Anti-censorship team meeting notes, 2024-12-12
by Shelikhoo 12 Dec '24

12 Dec '24

Hey everyone! Here are our meeting logs: http://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-12-12-16.00.html And our meeting pad: Anti-censorship work meeting pad -------------------------------- Anti-censorship -------------------------------- Next meeting: Thursday, December 19 16:00 UTC Facilitator: meskio ^^^(See Facilitator Queue at tail) Weekly meetings, every Thursday at 16:00 UTC, in #tor-meeting at OFTC (channel is logged while meetings are in progress) This week's Facilitator: shelikhoo == Goal of this meeting == Weekly check-in about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship at the Tor Project and Tor community. == 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 projects, we are working on: * All needs review tickets: * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/merge_requests?s… * Project 158 <-- meskio working on it * https://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues/?label_na… == Announcements == * Azure CDN from Edgio (azureedge.net) is due to be shut down as early as 2025-01-15: https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * We stopped using snowflake-broker.azureedge.net in 2021: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_re… * But it still receives traffic somehow: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… * onionwrapper still uses snowflake-broker.azureedge.net: https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… * (also, anything still using snowflake-broker.azureedge.net is using the old broker, see discussion below) * == Discussion == * Creating container mirror for anti-cenosorship projects to deal with docker hub restriction * https://gitlab.torproject.org/tpo/tpa/team/-/issues/41914#note_3138851 * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * we'll create a repo in gitlab that mirrors the needed images by it's CI * WIP MR: Add covert-dtls to proxy and client * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * is a big change, shelikhoo did review it but more eyes are needed * cohosh will look into it * Reasonable PollInterval for Orbot? https://github.com/tladesignz/IPtProxy/pull/58 * standalone proxy does 5seconds poll interval * orbot was doing the same but being mobile it might be better to be slower * 120sec sounds like a good number seeing that there are already a lot of proxies new 2024-12-12 * snowflake-broker.azureedge.net is pointing to snowflake-broker.bamsoftware.com as the origin, which still points to the old Debian 10 broker (#40349). * dcf will update the Azure configuration to use snowflake-broker.torproject.net as the broker instead * dcf will delete the snowflake-broker.bamsoftware.com DNS record * Ok to turn off the old snowflake broker now? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… * Yes, okay to shut it down. shelikhoo suggests turning it off but not deleting the instance for a week or so, in order to see what might still be using it. * > what was that censorship alerts mailing list? * https://lists.torproject.org/mailman3/postorius/lists/anti-censorship-alert… ? no, not that one * On Identifying Anomalies in Tor Usage with Applications in Detecting Internet Censorship * https://arxiv.org/abs/1507.05819 * https://censorbib.nymity.ch/#Wright2018a * "infolabe-anomalies", though the mailing list archives may be offline now? * GeKo: we have been in contact with the "On Identifying Anomalies" team recently, related to https://gitlab.torproject.org/tpo/network-health/team/-/issues/94 "Set up a detection and notification system of anomalies in Tor and bridge usage". * The issue on the anti-censorship-team is https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… "Add prometheus alerts to indicate potential censorship events". cohosh will contact GeKo about it. * 2009: "An anomaly-based censorship-detection system for Tor" https://research.torproject.org/techreports/detector-2011-09-09.pdf * which is what powers the censorship events at e.g. https://metrics.torproject.org/userstats-relay-country.html?start=2024-09-1… and https://metrics.torproject.org/userstats-censorship-events.html * Azure CDN from Edgio shutdown * Might make our meek builtin bridge stop working, requiring a change or removal as a default option * cohosh will follow up with micah == 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. cecylia (cohosh): 2024-12-10 Last week: - wrote a STUN torrc check tool - https://gitlab.torproject.org/cohosh/stun-torrc-check - continued exploring options for metrics - gitlab reviews and todos This week: - work on snowflake broker metrics improvements - write a script to easily test STUN servers in snowflake's torrc - finish snowflake dependency upgrades that were causing problems - take a look at snowflake web and webext translations and best practices - make changes to Lox encrypted bridge table - https://gitlab.torproject.org/tpo/anti-censorship/lox/-/merge_requests/147 Needs help with: - what was that censorship alerts mailing list? dcf: 2024-12-12 Last week: - made a graph of snowflake users in Russia in November 2024 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - snowflake azure cdn bookkeeping https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Snowflake-co… - commented on unreliable snowflake data channel rev2 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next week: - open issue to have snowflake-client log whenever KCPInErrors is nonzero https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - parent: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - open issue to disable /debug endpoint on snowflake broker Help with: meskio: 2024-12-05 Last week: - rdsys stopped accepting new bridges (rdsys#249) - deploy onionsproutsbot distributing TorBrowser for win7 (onionsproutsbot#64) - support webtunnel bridge operators - prepare splintercon presentations - more grant writting life - review BridgeDB deprecation blogpost Next week: - AFK at splintercon Shelikhoo: 2024-12-12 Last Week: - [Pending] snowflake broker update/reinstall(cont.): https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - [Awaiting Review] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Merge request reviews - Work on finishing snowflake container release(and fix the comments) - Incorrectly flattened container image with "pull" command https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… - Seperate Docker Hub mirroring to a Seperate Stagehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports… Next Week/TODO: - Merge request reviews - [Resume] Unreliable+unordered WebRTC data channel transport for Snowflake rev2 (cont.)( https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… ) improvements - Analysis Iran vantage point result onyinyang: 2024-12-12 Last week(s): - Fixed up Troll-patrol MR - Worked on deploying test distributor - need to enable service on the test server Next week: - update lox protocols to return duplicate responses for an already seen request - Continue work on implementing issuer efficiency for check-blockage and trust-promotion protocols - Work on outstanding milestone issues: in particular: https://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/69 - key rotation automation Later: pending decision on abandoning lox wasm in favour of some kind of FFI? https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43096) - add pref to handle timing for pubkey checks in Tor browser - add trusted invitation logic to tor browser integration: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42974 - improve metrics collection/think about how to show Lox is working/valuable - sketch out Lox blog post/usage notes for forum (long term things were discussed at the meeting!): - brainstorming grouping strategies for Lox buckets (of bridges) and gathering context on how types of bridges are distributed/use in practice Question: What makes a bridge usable for a given user, and how can we encode that to best ensure we're getting the most appropriate resources to people? 1. Are there some obvious grouping strategies that we can already consider? e.g., by PT, by bandwidth (lower bandwidth bridges sacrificed to open-invitation buckets?), by locale (to be matched with a requesting user's geoip or something?) 2. Does it make sense to group 3 bridges/bucket, so trusted users have access to 3 bridges (and untrusted users have access to 1)? More? Less? theodorsm: 2024-12-05 Last weeks: - Adjusting to post-student life - WIP MR: Add covert-dtls to proxy and client - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Next weeks: - Test Snowflake fork with covert-dtls - Condensing thesis into paper (on hold) Help with: - Test covert-dtls in Snowflake Facilitator Queue: meskio onyinyang shelikhoo 1. First available staff in the Facilitator Queue will be the facilitator for the meeting 2. After facilitating the meeting, the facilitator will be moved to the tail of the queue

1 0