Re: [tor-relays] Snowflake vs bridge on home connection on a Raspberry Pi 4
Hey Cristian, you could run both, but some people think it's not the best idea because if one service gets blocked the other one is also affected. With dynamic IP addresses, also if they're only changing every other few days, its probably better to run a snowflake proxy as obtaining new bridges for tor users is a bigger effort than connecting to a snowflake proxy (snowflake was kinda more intended to offer proxy services with changing IP addresses and behind NAT...). Best, fran On 3/19/22 01:02, Cristian Consonni via tor-relays wrote: Hi all, I have a fiber connection at home and I would like to run a bridge or standalone Snowflake proxy on a dedicated Raspberry Pi 4. I have been reading some threads [1][2] from this list about the topic, but it is not completely clear to me what would be the best choice. The requirements [3] for running a bridge are 24/7 connectivity and the ability to expose TCP ports; however, I have read that it is also preferred that you have a static IP to run a bridge (in the page about the recent campaign about bridges, having a static IP was listed as a requirement [4]). In principle my home connection has a dynamic IP, but I have been logging my IP address for the last few days and it seems quite stable (it has not changed for the last 4 days). What's the best choice? Can I run both? Best, Cristian [1]: https://lists.torproject.org/pipermail/tor-relays/2022-February/020298.html [2]: https://lists.torproject.org/pipermail/tor-relays/2022-February/020355.html [3]: https://community.torproject.org/relay/setup/bridge/ [4]: https://blog.torproject.org/run-a-bridge-campaign/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Bridge lifecycle expectations
Hi All, I have three lifecycle questions: 1) How long is typical (or what factors are involved ) before the bridge address is given out to users. 2) How do I know when the bridge is burned (identified and blocked) 3) When it is burned and I build a new one on an other address should I copy the key with the config to maintain "trust" continuity or is that neutral or bad for bridges? As a little context I've run relays before and just started up an obfs4proxy Bridge (well 10days ago). https://bridges.torproject.org/status?id= says it's good, logs look good but I've yet to see any real traffic, just the same 8 German node that I presume are Tor infrastructure checking status. $ cat bridge-stats bridge-stats-end 2022-03-22 18:44:43 (86400 s) bridge-ips de=8 bridge-ip-versions v4=8,v6=0 bridge-ip-transports =8,obfs4=8 every day is the same (other than bridge-stats-end) Thanks, A. Pleb signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge lifecycle expectations
Quoting Just a Pleb (2022-03-23 02:43:54) > 1) How long is typical (or what factors are involved ) before the bridge > address is given out to users. It should take less than 3 hours to start being taken into account by rdsys/bridgedb. But unless you configure a specific distributor you will be assigned randomly to one and depending on the distributor it might have different ways to distribute bridges or it might get into the 'reserve' which means is a bridge reserved and not distributed (yet). > 2) How do I know when the bridge is burned (identified and blocked) Usually a 'burnded' bridge is a per country situation, I mean your bridge might be burned in Russia but be still working in Iran. You can monitor how many connections you get from each country (by looking at stats/bridgestats) and if you were getting many connections from a certain country and they drop to 0 that means your bridge is burned in that country. > 3) When it is burned and I build a new one on an other address should I copy > the key with the config to maintain "trust" continuity or is that neutral or > bad for bridges? No, is better to set up a new bridge. An attacker that knows the bridge fingerprint can get access to the rest of the bridge information. I will recommend setting up a fresh new bridge if you consider yours burned. > As a little context I've run relays before and just started up an obfs4proxy > Bridge (well 10days ago). BTW, is not recommended to run exit relays and bridges by the same organization, as the family parameter doesn't exist for bridges. > https://bridges.torproject.org/status?id= > > says it's good, logs look good but I've yet to see any real traffic, just the > same 8 German node that I presume are Tor infrastructure checking status. What distributor the metrics website say your bridge is in? https://metrics.torproject.org/rs.html#search/ Your bridge might be assigned to a distributor that is not in use yet (like settings or telegram), but will be very useful in the coming weeks. BTW, ip counting is rounded to 8, so seeing 8 might mean you have a single client connecting to it or up to 8. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge lifecycle expectations
Hi meskio, Thanks for the detailed response. My bridge has been assigned to telegram so that explains why it's not active yet. Watching per country stats makes sense for determining where the bridge has been blocked. Also good to know the bridge state should be fully disposed when recycling rather than preserved for reputational purposes. Follow up question on running bridges and relays. If the consensus is I should pick Relays xor Bridges to run I will but I'm not fully convinced that's the right trade off for capacity -vs- security given "good actors" wouldn't attack the traffic and bad actors wouldn't obey the injunction the only extra security impact I see is limiting damage from "good actor who get compromised" which is *some* obviously... Thanks signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Ports blocked
Looks like my ISP has shut me down. The ports I were using are now blocked. I checked them with an online port checker. I tried. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] update obfs4proxy if you run a bridge
On 3/21/22 18:45, meskio wrote:
Thank you for running bridges,
let me know if you need any help upgrading it.
I'm not really familar with Debian and do wonder, what line I have to
add to /etc/apt/apt.conf.d/50unattended-upgrades to get that
automatically installed ? Maybe I need to add the repo too ?
Currently it looks like:
~# cat /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
"origin=TorProject";
};
Unattended-Upgrade::Package-Blacklist {
};
Unattended-Upgrade::Automatic-Reboot "true";
--
Toralf
OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] update obfs4proxy if you run a bridge
On Wednesday, March 23, 2022 6:08:10 PM CET Toralf Förster wrote: > On 3/21/22 18:45, meskio wrote: > > > Thank you for running bridges, > > let me know if you need any help upgrading it. > > > I'm not really familar with Debian and do wonder, what line I have to > add to /etc/apt/apt.conf.d/50unattended-upgrades to get that > automatically installed ? Maybe I need to add the repo too ? > Yes, first edit '/etc/apt/sources.list': # bullseye-backports, previously on backports.debian.org deb http://deb.debian.org/debian/ bullseye-backports main #deb-src http://deb.debian.org/debian/ bullseye-backports main Then install: apt update apt install -t bullseye-backports obfs4proxy https://backports.debian.org/Instructions/ You should always install individual packages from the backports archive. Don't use apt-pinning for the whole backport archive in '/etc/apt/preferences'. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
