Re: [tor-relays] Possible compression bomb, abandoning stream message received
Le Thu, Nov 05, 2020 at 10:36:15AM -0800, Keifer Bly écrivait : > >Hi, > > >My bridge at >[1]https://metrics.torproject.org/rs.html#details/EF36AE38C162E96E0645E >1DF25EF19522ADBAF90 > > >Suddenly received a message saying [warn] Possible compression bomb, >abdnoning steam. Not sure what this means, but the bridge does appear >running, saying it has pushed 3 GB within the last 7 days. It just >seems odd as looking it has logged this message a huge number of times >within an hour or so. > > >Thank you. I am wondering what this message means? > > > >--Keifer > If you read all the mails, i have already sent a mail about this, and I'm working on an investigatory patch to find out where it comes from. It might be from the 253 new relays added in the same time for only 12 hours but we do need to have a better way to understand this kind of problem anyway. Cheers, -- Guinness signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Log warning : possible (zlib) compression bomb on middle relays
Hi all, We are at least 3 users running middle relays from 0.4.4.5 and after having some logs like those : ``` Nov 02 05:30:55.000 [warn] Possible compression bomb; abandoning stream. Nov 02 05:30:55.000 [warn] Possible zlib bomb; abandoning stream. Nov 02 05:30:56.000 [warn] Possible compression bomb; abandoning stream. Nov 02 05:31:00.000 [warn] Possible compression bomb; abandoning stream. Nov 02 05:31:00.000 [warn] Possible compression bomb; abandoning stream. Nov 02 05:31:00.000 [warn] Possible compression bomb; abandoning stream. Nov 02 05:31:55.000 [warn] Possible compression bomb; abandoning stream. Nov 02 05:31:56.000 [warn] Possible compression bomb; abandoning stream. ``` I'm wondering if this is an attack or a new feature (haven't checked yet) but I'd like to know how many users are impacted. The interesting informations are : * Number of warnings * What kind of relay it is (middle, exit, entry) After your answers, I'll complete the issue I have opened on the bug tracker. Cheers, -- Guinness signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How long does it take for a relay IP to stop being displayed in metrics and web service?
Le Wed, Oct 28, 2020 at 06:53:56AM +, shsmbcfdfk écrivait : > Hi, > > I setup a non-exit relay on my home network and I have been listed as relay. > So now me and my family even if we don't use Tor we are excluded from some > online services. > > Beyond the discussion of whether the owners of these services understand Tor > or not, it's a problem that the address is added to public lists, especially > for non-exit relays. > > I completely shut down the relay several hours ago but my IP is still listed. > > My question is how long does it take for a relay to disappear ? > > Thanks, It depends on their firewall policy, if they use fail2ban or not, how long they blacklist. But usually the default is 24h from what I have seen. You might want to contact them to ask to be removed from the blacklist, and mayber explain them why you use Tor and why this is important ? -- Guinness signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Le Wed, Jul 08, 2020 at 05:22:44PM +0200, Toralf Förster écrivait : > On 7/8/20 12:35 PM, Roger Dingledine wrote: > > * One is dividing the network into known and unknown relays, where we > > reserve some minimum fraction of attention for the known relays. Here > > the next steps are to figure out how to do load balancing properly with > > this new parameter (mainly a math problem), and to sort out the logistics > > for how to label the known relays so directory authorities can assign > > weights properly (mainly coding / operator ux). > > Which boils down to "subjective" versus "objective" criterias of a weight > distribution algorithms. > > Which is fine as long as the maths behind it is public available and > understandable. > > This would enable a relay operator to verify/falsify it. > I'm pretty sure the maths behind it will be public. For the "understandable" part, I guess there can be a double explanation, one for the mathematicians/CS that know/understand the maths, and a popularisation of this explanation for those who don't understand the maths. Cheers, -- Guinness ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Hi all, Le Mon, Jul 06, 2020 at 07:07:19AM -0400, Roger Dingledine écrivait : > > Three highlights from that ticket that tie into this thread: > > (A) Limiting each "unverified" relay family to 0.5% doesn't by itself > limit the total fraction of the network that's unverified. I see a lot of > merit in another option, where the total (global, network-wide) influence > from relays we don't "know" is limited to some fraction, like 50% or 25%. That's a great idea, but how do you say you "know" a relay ? And in this case, I guess that this number should stay low. Here we have a case of 20% exit probability by this group of nodes, which is already huge. And we don't necessarily know if they have as well a part of the entry nodes. > > (B) I don't know what you have in mind with verifying a physical address > (somebody goes there in person? somebody sends a postal letter and waits > for a response?), but I think it's trying to be a proxy for verifying > that we trust the relay operator, and I think we should brainstorm more > options for achieving this trust. In particular, I think "humans knowing > humans" could provide a stronger foundation. > > More generally, I think we need to very carefully consider the extra > steps we require from relay operators (plus the work they imply for > ourselves), and what security we get from them. Is verifying that each > relay corresponds to some email address worth the higher barrier in > being a relay operator? Are there other approaches that achieve a better > balance? The internet has a lot of experience now on sybil-resistance > ideas, especially on ones that center around proving online resources > (and it's mostly not good news). Two points here : * We should give a read to the sybil-resistance litterature around to see what exists and how it could be adapted to Tor. I know that a lot of work has already been done, but maybe some extended defenses are required at this point. * A suggestion would be to build a web-of-trust between relay operators, using, I don't know, PGP or something like this, and organize signing parties at hackers/Torproject/dev events? For example, I'm every year at FOSDEM in Brussels, and I attend the bird of feathers for Tor when it exists. However, it would prevent people who want to keep complete anonymity from contributing to Tor, which is a bad point. Maybe this lights something up in your brains? > > (C) Whichever mechanism(s) we pick for assigning trust to relays, > one gap that's been bothering me lately is that we lack the tools for > tracking and visualizing which relays we trust, especially over time, > and especially with the amount of network churn that the Tor network > sees. It would be great to have an easier tool where each of us could > assess the overall network by whichever "trust" mechanisms we pick -- > and then armed with that better intuition, we could pick the ones that > are most ready for use now and use them to influence network weights. > > > > At the same time, we need to take other approaches to reduce the impact > and incentives for having evil relays in the network. For examples: > > (1) We need to finish getting rid of v2 onion services, so we stop the > stupid arms race with threat intelligence companies who run relays in > order to get the HSDir flag in order to scrape legacy onion addresses. Good point. Do you think speeding the process is possible? The deadline is in more than one year from now, which seems a pretty long time. Or maybe is it to synchronize with new versions of the linux/BSD distributions? > > (2) We need to get rid of http and other unauthenticated internet protocols: > I've rebooted this ticket: > https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850 > with a suggestion of essentially disabling http connections when the > security slider is set to 'safer' or 'safest', to see if that's usable > enough to eventually make it the default in Tor Browser. +1, nothing more to say. > > (3) We need bandwidth measuring techniques that are more robust and > harder to game, e.g. the design outlined in FlashFlow: > https://arxiv.org/abs/2004.09583 I have seen that there is a proposal, and a thread on tor-dev that died in April (lockdown maybe?), maybe we should launch again the discussions around this technique? -- Guinness ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why are my relays flagged?
Le Thu, Dec 20, 2018 at 06:26:52AM -0500, Matt Traudt écrivait : > Because 0.3.4.9 is out. > > Sometimes the old version will stop being recommend before the new > version is available in various repositories, but that doesn't seem to > be the case here. I see 0349 for bionic on deb.tpo > > apt update, apt upgrade, systemctl restart tor > > Matt > > On 12/20/18 6:21 AM, Langrehr, Jan Christian wrote: > > Hello everyone, > > > > > > I'm wondering why both of my Tor relays are flagged for running an > > unstable or outdated version or Tor. I'm running my relays on Ubuntu > > 18.04 and I get Tor from the > > > > deb https://deb.torproject.org/torproject.org bionic main repository. > > Both of my relays run Tor version0.3.4.8. > > > > My relays are > > https://metrics.torproject.org/rs.html#details/9EDA50493B537837E72D83090BE4ED99A5341987 > > and > > https://metrics.torproject.org/rs.html#details/8E57A56487EEA341965B77AE132E4856A0B69382 > > > > > > I'm looking forward for an anwser. > > > > Thank you all very much Hi, For relays, I stronlgy recommend using unattended-upgrades, as described in this guide : https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpdates This way, your relay will be up to date, and with a simple email config, you can easily receive some updates everytime an upgrade has been processed! Cheers, -- Guinness signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas is now Relay Search!
Le Tue, Nov 14, 2017 at 12:52:27PM +, Iain R. Learmonth écrivait : > > Hi All, > > You may notice that Atlas has a new look, and is no longer called Atlas. > For now no URLs have changed but this is part of work to merge this tool > into the Tor Metrics website. > > The style is determined by the Tor Metrics Style, and modifications have > been made to fit this. > > The decision was made to deploy these changes before the actual > integration into metrics.torproject.org to allow for other issues to be > worked on. This was a big change and it was tricky maintaining two > branches of the codebase. > > Issues should still be reported on the Metrics/Atlas component in the > Tor trac if they arise. When we come to full integration, URLs will > change but there will be a period where we maintain redirects to prevent > any URLs from breaking while waiting for being updated. > > Thanks, > Iain. > Hi! Thanks for this new interface! Is it just me or is the font way bigger than it used to be with Atlas? I personnaly find it too big, but it is just some cosmetics :) Cheers, -- Guinness signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Hi! Thanks for this great job! Dunno if it is an expected behavior or not, but when I enter the menu, the gui is updated once after the first keypress, and then is not updated at all then until the menu is left. Then all missed frames are caught up when leaving the menu. This gives a weird feeling with graphs being updated extremely fast. I am running debian stretch. Cheers, -- Guinness signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
