Hi,
Thanks all for joining the Tor Relay Operator Meetup!
You can find the meetup notes below.
The next Tor Relay Operator online meetup is July 29, 2023 @ 18 UTC.
cheers,
Gus
## Tor Relay Operator Meetup - 2023-06-24
### Before we start
Tor operators are recommended to read the Tor Code of Conduct and
Expectations of Tor Operators.
Tor Code of Conduct:
https://gitlab.torproject.org/tpo/community/policies/-/blob/master/code_of_conduct.txt
Expectations for Relay Operators:
https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-Relay-Operators
### 1. Announcements
1.1. In-person activities
- Tor Relay Operators meetup @ Bornhack
(https://bornhack.dk/bornhack-2023/) in August (Denmark). Ping Alex
(ahf) for more information.
- Tor Relay Operators meetup @ CCCamp 2023. CCCamp
(https://events.ccc.de/camp/2023/infos/) is taking place near
Berlin, Germany, in August. Ping gus or other tor people if you want to
help.
1.2. More unrestricted snowflake proxies are needed
- Context: Snowflake is very popular in Iran and China. See the Tor
metrics graphs:
- https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-03-26&end=2023-06-24&country=ir
- https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-03-26&end=2023-06-24&country=cn
- But there is an issue: many snowflake proxies (volunteers) are
behind "restricted connections," including NAT and packet filtering.
'Unrestricted' snowflake proxies will work with all snowflake clients,
even those with the most restrictive symmetric NATs and filtering
behaviour.
- Current stats:
snowflake-ips-nat-restricted 72006
snowflake-ips-nat-unrestricted 2447 <- We need your help to increase this pool!
snowflake-ips-nat-unknown 47623
- To understand Snowflake NAT matching behavior, please check out this
documentation:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching
- Maybe there should be a guide on how to go from being restricted to
unrestricted for standalone snowflake proxy from home and/or from a
server with a firewall (i.e. limit the range used by snowflake, and
"find how to open a range of port on your router").
- Recommendation: Do not run snowflake proxy on the same IP as a
relay/bridge. It's a good call to run it on a machine with public
dynamic IP address.
1.3. Relays EOL (0.4.5.x) removal
- Only public relays running 0.4.5.x are affected; bridges are
unaffected.
- If your relay was blocked because was running tor 0.4.5.x version,
please reach out to bad-relays at lists.torproject.org and ask them
to unblock your relay.
- Issue:
https://gitlab.torproject.org/tpo/network-health/team/-/issues/291
1.4. IPv4 limit proposal (bumped limit from 2 to 4, and soon 4 to 8!)
- Proposal: https://gitlab.torproject.org/tpo/core/tor/-/issues/40744
- Currently we're allowing 4 relays per IPv4 address. This new max
allowed relays per IP address was analyzed here:
https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/51
- We're considering to bump the limit to 8 relays per IPv4 address.
1.5. Tor Forum is now self-hosted by Tor Project
- The Tor Forum migration was completed last week:
https://forum.torproject.org/
- tor-talk will be deactivated next week. The mailing list archive
will be publicly available. Other mailing lists aren't affected.
- The Tor Forum Privacy policy will be updated.
### 2. Presentation about Webtunnel bridges with Tor Anti-censorship
Team
Tor Anti-censorship Team is soft-releasing Webtunnel, a new pluggable
transport based on HTTP Upgrade (HTTPT). It is designed to hide behind
HTTPS servers to resist against active probing attacks and to
effectively blend in with Internet traffic.
Bridge operators can deploy this new pluggable transport on the same
IP/machine if they are already running obsf4.
Please don't expect a lot of users at the moment, bceause webtunnel is
only available on Tor Browser Alpha.
Slides: https://nc.torproject.net/s/PP98BXDMk8nwtrn
Webtunnel requirements for operators:
- A self-hosted HTTPS website
- Handle traffic with configurable reverse proxy
- Environment to run Tor bridge
- (Optional) Container runtime like Docker
You can find instructions on how to deploy webtunnel here:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/blob/main/README.md
A Dockerfile is available for use with a Debian container and a package
for FreeBSD has been created.
Q: What is the distribution mechanism?
A: At the moment webtunnel is being distributed only via "HTTPS"
(https://bridges.torproject.org).
Q: Are the regular traffic patterns of webtunnel-transported traffic
similar to tor traffic? Are they usually bi-directional
No, the traffic looks like HTTPS.
### 3. Tor Network Health proposals discussion
- Meta proposal discussion:
https://gitlab.torproject.org/tpo/community/policies/-/issues/2
- contactinfo proposal discussion:
https://gitlab.torproject.org/tpo/community/relays/-/issues/71
The contactinfo proposal: we don't need to rush as this is a proposal
for Arti relays, which won't happen any time soon (probably is not
happening for the next 2 years), but we should start scoping which
fields the community want.
### 4. Next Tor Relay Operator Meetup
- Date: July 29, 2023 at 18:00 UTC.
### 5. Q&A
Q: I am conducting a survey to understand the attitudes of relay
operators towards current relay updates and a new automatic update
design. How should I approach contacting relay operators? I apologize
for any potential lack of knowledge in this area, as I am new to this
field and seeking guidance on the best practices for engaging with relay
operators.
A: Please contact gus and geko by email, so they can evaluate your
request.
Q: Will the obfs fork affect the future development of obfs/its fork?
A: We plan to continue the development of obfs4 in lyrebird, but there
is probably not going to happen much in any near future. Bridge
operators don't need to migrate to lyrebird yet, is great if they do,
but we haven't packaged it to debian or any distro, neither use it yet
in our docker images. For now the changes in our fork only affect meek.
tl;dr: bridge operators don't need to do anything yet, just keep an eye
for it.
Q: Any plans, ETA, or budget estimation for running relays using Arti?
A: No, not yet. We don't have any funded project to develop Arti
relays and this process will take time (it's not part of 2023/2024
roadmap). Relay Operators will be involved when the time comes.
Q: Are unrestricted snowflake proxies currently more needed than obfs4
bridges?
A: Depends on the type/location of user you are wanting to help most.
Bridges/Relays are best for static IPs, snowflake for dynamic addresses.
E.g. Snowflake is used more than obfs4 in China, obfs4 more than
Snowflake in Russia.
Q: When should someone run a snowflake proxy instead of a bridge or
relay?
A: Snowflake proxies tend to use less bandwidth than a relay/bridge.
Snowflakes work with dynamic IPs eg at home.
Q: ipv4 limit relaxation - is that due to carrier-grade NAT being used
more and more?
A: Not really. It's more that servers got more powerful over time and
IPv4 addresses more expensive. Thus, the cost for relay operators
running more relays got higher while resources got wasted, which is
hurting good operators. We try to accommodate that with allowing more
relays per IP address while keeping the network monitored so that sybil
attacks are not a danger and get dealt with quickly.
Q: What is the status regarding ddos?
A: The main ddos seems to be stopped, but some exit operators are having
issue with their DNS resolver.
Q: How meaningful is it at all to run an obfs4 bridge on the network of
a big hoster like Hetzner (regarding situations like in Turkmenistan, as
mentioned in one of the last meetings - possibly those countries block
whole IP ranges from such hosters)?
A: It's very meaningful to use big hosters as blocks can cause a lot of
collateral damage. You shouldn't really need to find an obscure hoster.
For Turkmenistan, bridges running on obfs4 port 80, 443 or 8080 and
residential connections seems to work!
Q: Is there a plan to have IPv6 only Relay (way cheaper)?
A: Not really because relays must be reachable by the rest of the Tor
network.
Q: What does it mean if no Bandwidth Ratio is displayed on
bridges.torproject.org scanner (while obfs4 reachability is displayed)?
(For one of my bridges, there is no "Bandwidth ratio" entry, but a
"obfs4: functional" and a "Last tested" entry)
A: The bandwidth ratio is the ratio of how fast is this bridge compared
to the rest of bridges. it means that the bandwidth is not being tested
yet by onbasca, it could be that onbasca has failed to test it or just
need a bit longer, but we don't distribute bridges with low ratio.
On Sat, Jun 24, 2023 at 06:46:08PM +0200, lists@xxxxxxxxxxxxxxx wrote:
> On Samstag, 24. Juni 2023 18:03:47 CEST lists@xxxxxxxxxxxxxxx wrote:
> > On Dienstag, 20. Juni 2023 23:01:23 CEST gus wrote:
> > > Just a friendly reminder that the Relay Operator meetup will happen this
> > > Saturday, June 24 at 18 UTC.
> > >
> > > ## Agenda
> > >
> > > 1. Announcements
> > >
> > > - Tor Relay Operators meetup @ CCCamp 2023!
> > > - More unrestricted snowflake proxies are needed
> > > - Relays EOL (0.4.5.x) removal
> > > - IPv4 limit proposal
> > >
> > > 2. Presentation about Webtunnel bridges with Tor Anti-censorship Team
> > >
> > > 3. Tor Network Health proposals discussion
> > >
> > > - Meta proposal discussion
> > > - contactinfo proposal discussion
> > >
> > > 4. Q&A
> > >
> > > https://pad.riseup.net/p/tor-relay-op-meetup-june-keep
> >
> > https://pad.riseup.net/ is down :-(
> > As an alternative, the 'German riseup' systemli could be taken. systemli.org
> > is hosted on its own servers at Community-IX.
> >
> > https://pad.systemli.org/p/tor-relay-op-meetup-june-keep
>
> I think gus copied the pad. Thanks. Hidden service link is:
> http://mjrkrqnlf26etelsi7zpkqc3dzlrzyurvmd3jksmndarzzbugz5xctid.onion/p/tor-relay-op-meetup-june-keep
>
> --
> ╰_╯ Ciao Marco!
>
> Debian GNU/Linux
>
> It's free software and it gives you freedom!
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
--
The Tor Project
Community Team Lead
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays