Re: [tor-relays] Could Zoom be using the wrong dan-tor blacklist
Gus, It's "OnNoNotAnotherTorRelay"; D195E5CE8AE77BAC91673E6CFB7BD0AF57281646 Cheers. On 9/9/2020 7:44 PM, gus wrote: Hi Eddie, Could you inform your relay fingerprint? Thanks, Gus On Mon, Sep 07, 2020 at 11:54:47AM -0700, Eddie wrote: Starting yesterday (maybe Saturday) we have been unable to initiate any Zoom calls. They just sit "connecting". According to Zoom, there are no issues that would lead to this. My investigation, traces I have run on the server, and using a VPN (on a tablet on my LAN) show the exact same symptoms I had a year (or so) ago with a couple of AT sites, which I eventually narrowed down to being caused by the same blacklist by routinely switching IPs and then eventually shutting down my relay temporarily. Is anyone else seeing similar and/or have any suggestions as I rather not have to shut my relay down. Running a multitude of VPNs on my internal machines is not really an option and my relay isn't going to function if I throw a VPN on my server. Cheers. ___ 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] SMTP port 465/587
Hi, question for Tor exit relay operators. Do exit relay operators allow connections to SMTP port 587 more than port 465? The RiseUp webpage says “SMTP port 465 is often blocked by Tor exit nodes but port 587 is less frequently blocked” (https://riseup.net/en/email/clients) because port 465 is considered deprecated (see RFC 8314). In practice do most exit relay operators allow connections to both SMTP ports? Thanks ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] non-encrypted connections from Tor exit relays
hi, generalized question about Tor exit relays and exit relay operators. do some exit relay operators have a policy to prevent connections leaving their exit node via non-encrypted ports (e.g. port 25)? this could be a philosophical position - not even wanting to be in a position to observe users' data passing through the exit node in clear text. or a pragmatic position - hoping that encrypted connections provide some level (even very weak) of plausible deniability in the event that a connection attracts the attention of law enforcement. this is just my thoughts. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] OVH Mitigation
On Thu, Sep 10, 2020 at 8:48 AM Dr Gerard Bulger wrote: > I know we should dilute our dependence on OVH, but cheap and seem to > ignore the fact the machine is an exit node. > > > > OVH has a seemingly patented a system to deal with denial of service > attacks. I am not sure what they detect but when they do we get this: > > > > *“We have just detected an attack on IP address x.x.x.x. In order to > protect your infrastructure, we vacuumed up your traffic onto our > mitigation infrastructure. The entire attack will thus be filtered by our > infrastructure, and only legitimate traffic will reach your servers. At the > end of the attack, your infrastructure will be immediately withdrawn from > the mitigation”* > > > I have a server (not a relay) with OVH, and also started receiving these recently. I raised a ticket with them to ask for more information about the detected attack (what port/proto etc) because there are legitimate uses that may look a bit like an attack (the boxes sit behind a CDN, so you can end up with a lot of requests/connections from not may IPs) Worryingly, they couldn't actually tell me - all I managed to get back was "looks like it's a false positive". It's triggered a few times since, with no sign of anything even remotely suspicious in my traffic graphs. I know this doesn't really add much knowledge about what they're detecting, but the point is more that they don't seem to be overly clear themselves -- Ben Tasker https://www.bentasker.co.uk ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] OVH Mitigation
On Wed, Sep 09, 2020 at 12:00:37PM +0100, Dr Gerard Bulger wrote: > To be fair, the automated system takes it off after an our or two. If my > tor server is left in this mitigated state, the tor exit gets labelled a BAD > EXIT which is something to avoid as takes days to be trusted again. Can you point us to which relay this happened to, and an approximate timestamp? We don't badexit that many relays these days, so I am wondering if something else is going on instead. Thanks, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] OVH Mitigation
I know we should dilute our dependence on OVH, but cheap and seem to ignore the fact the machine is an exit node. OVH has a seemingly patented a system to deal with denial of service attacks. I am not sure what they detect but when they do we get this: "We have just detected an attack on IP address x.x.x.x. In order to protect your infrastructure, we vacuumed up your traffic onto our mitigation infrastructure. The entire attack will thus be filtered by our infrastructure, and only legitimate traffic will reach your servers. At the end of the attack, your infrastructure will be immediately withdrawn from the mitigation" To be fair, the automated system takes it off after an our or two. If my tor server is left in this mitigated state, the tor exit gets labelled a BAD EXIT which is something to avoid as takes days to be trusted again. As soon as I get their email I now stop TOR to prevent that embarrassing label, and perhaps doing so stops whatever it is OVH is detecting. Being shutdown for a few hours seems better than being a bad exit. Gerry ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
