Re: [tor-relays] 7000 concurrent connections

2024-02-20 Thread admin--- via tor-relays
Just try it!

Tor will limit the amount of connections it accepts based on how much RAM you 
have.



\ Original Message 
On Feb 20, 2024, 06:16, snowmanonahoe--- via tor-relays < 
tor-relays@lists.torproject.org> wrote:

>
>
>
> Hello all,
>
>
>
>
> I'm interested in running a relay. I should meet all the requirements for a 
> guard/middle, except handling 7000 concurrent connections, which I'm unsure 
> of. The website seems to tell me to try it and see what happens, but what 
> exactly am I watching out for? Is the router going to fail entirely, slow 
> down, or something else?
>
>
>
>
> Thanks in advance.
>
>
>

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] request for receipes MULTI-instances of ethe4 Guard, Bridge, Exits, snowflake , Tunnel, or both DEBIAN and OpenBSD

2024-02-08 Thread admin--- via tor-relays



You can have 2 separate relays on the same IPv4 address. Are you running into 
issues?

On Wednesday, February 7th, 2024 at 16:41, eff_03675...@posteo.se 
 wrote:
> 

> 

> 

> Hi,
> 

> I have been looking too far and for too long on solving multiple
> imstances / nodes per ONE IPv4,
> and found only outdated problems unwell built.
> 

> 

> Please when you have a bash sript / receipe,
> I would welcome that.
> 

> Hardening options would be very welcome too.
> 

> 

> C.
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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] Relay that's been running for a long time suddenly saying it's new?

2024-01-15 Thread admin--- via tor-relays
I had this issue too. It resolved itself shortly within a few hours.

 Original Message 
On Jan 15, 2024, 05:23, Petrarca via tor-relays wrote:

> Just to confirm - the same happens to my relay, so this seems to be a general 
> issue.
>
> Keifer Bly  schrieb am Montag, 15. Januar 2024 um 09:29:
>
>> Hi,
>>
>> So my relay at 
>> https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D
>>  is suddenly saying it's a new relay. Don't know why this would happen as 
>> it's been running for a few years, but suddenly saying it's new?
>>
>> Thanks.
>>
>> --Keifer___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Comcast blocks ALL traffic with tor relays

2023-06-12 Thread tor admin via tor-relays
If we could get EFF to announce a boycott of any corporation known to 
act maliciously against Tor or other privacy-friendly technology (such 
as VPNs), that would go a long way.


I will also write to EFF.  I have donated money to them, so maybe they 
will listen.  If they won't support a boycott directly, maybe at least 
they will comment on the issue publicly, and that would help launch a 
boycott.


If will also help to get an official communication from Comcast saying 
they are blocking Tor.  If they won't admit this, it makes it that much 
harder to fight.  I can't do this as I'm not a Comcast customer.  Are 
there any Comcast customers that can get a Comcast rep to admit, in 
writing, that this is happening?







On 6/12/23 10:50, s7r wrote:

xmrk2 via tor-relays wrote:
Any ideas on how to combat this? I was thinking about including some 
false positives in tor relay list. Imagine including some Google 
servers' IP addresses - Comcast customers suddenly cannot connect to 
Google, unless Comcast stops this blocking... or simply whitelists 
Google. But those false positives sound ugly and a bit malicious, not 
sure it is a good idea.




This sucks big time, if true. I am trying to ping Comcast from a 
middle relay IP address and it seams, to work, I guess you mean 
AS33651 - Comcast Cable LLC. Anyway, it could be, at latest consensus 
there is no single relay (middle or exit) hosted in AS33651.


I am not sure about the false positive solution, I see only downsides, 
including but not limited to:


- it's not ethical for Tor Project to do this, e.g. stating another 
company's infrastructure (say Google IP address space) is part of a 
network when in fact its not. I get it that the goal is privacy 
oriented and in good faith (freedom faith) but it seams rather 
inappropriate;


- there is no evidence that a blocker might use a list of relays 
provided by Tor Project's metrics portal (I am confident nobody does 
it because it's less effective) - they can just run a Tor client and 
get a copy of a consensus and extract from there IP:PORT IPv6:PORT and 
do from there whatever they please;


- if you include such false positives in the consensus you have to 
simulate dummy Tor relays on those "hot" IP addresses, like providing 
an onion key, RSA identity and ed25519 identity, thus looking like a 
relay, state some bandwidth for it, etc - in this case how will a Tor 
client know which relay is dummy and which not, in order not to try to 
establish circuits that fail, ultimately producing a terrible user 
experience for all users. Same applies for other relays, not just 
clients, that need to produce connections with the dummy relays. If we 
somehow mark them as "dummy", it will be pretty stupid and obvious and 
waste of effort as the blocker can simply understand the "dummy" 
marker and it's done, I guess it's pretty obvious.


I already wrote about this publicly, and also wrote a mail to EFF. 
Hope I am not spamming, I feel this is quite important issue and am a 
bit frustrated by the lack of attention it gets.




Not at all, this is very interesting and not spamming at all. I think 
it is unacceptable for this to happen, and I think all Comcast 
customers should quit if this is true - large internet corporations 
are trying to move on from "IP address identifications" as in only a 
beginner that discovered the internet one week ago still thinks of the 
IP address as "identification of a certain individual / entity", 
everybody is moving to advanced layers of authentication on per device 
basis, cryptographic public key, etc. Comcast if they do such a thing 
they set themselves 25 years behind the industry they operate in. And 
this can create many unwanted effects, someone should try to do 
something about this but I am not sure what we Tor volunteers *can* do 
to help with this, especially the ones that are not Comcast customers. 
EFF is the best start IMO.



___
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


Re: [tor-relays] GPG Signatures

2022-07-27 Thread Admin via tor-relays
Hi there,



I have seen a couple of emails from Tor Project with the signature.asc file 
attached. I was wondering how I would go ahead and recreate this for myself.



Any help would be great,


Kind regards,

Leon
The content of this email is confidential and intended for the recipient 
specified in message only. It is strictly forbidden to share any part of this 
message with any third party, without a written consent of the sender. If you 
received this message by mistake, please reply to this message and follow with 
its deletion, so that we can ensure such a mistake does not occur in the future.



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Debian is not allowing tor to update despite it being listed as a trusted respritory

2022-05-04 Thread tor admin via tor-relays
Your sources.list file entry looks incorrect.  I would definitely not 
recommend using trust=yes for a repo like tor, as it bypasses apt's 
security checks.


According to the instructions you linked 
, your source for the 
tor packages should be listed in /etc/apt/sources.list.d/tor.list as 
something like:


deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] 
https://deb.torproject.org/torproject.org buster main
deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] 
https://deb.torproject.org/torproject.org buster main


The instructions tell you how to import the repo key as well:



# wget -qO- 
https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc 
| gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg 
>/dev/null




On 5/3/22 13:10, Keifer Bly wrote:
I am not sure how to get rid of the trusty / ubuntu packages? I simply 
followed the instructions here:


https://support.torproject.org/apt/tor-deb-repo/

Thanks.
--Keifer


On Mon, May 2, 2022 at 10:31 PM Keifer Bly  wrote:

Hi all,

So I am running a tor relay on Debian, but no matter what when
updating tor there is an “updating from such a respiritpry can’t
be done securely and is therefore disabled by default”. Here is
the log

Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]

Hit:2 http://deb.debian.org/debian buster InRelease

Get:3 http://deb.debian.org/debian buster-updates InRelease [51.9 kB]

Get:4 http://deb.debian.org/debian buster-backports InRelease
[46.7 kB]

Ign:5 http://ftp.de.debian.org/debian stretch InRelease

Hit:6 http://ftpde.debian.org/debian stretch Release

Ign:7 http://deb.torproject.org/torproject.org trusty InRelease

Ign:8 http://deb.torproject.org/torproject.org trusty Release

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Ign:14 https://deb.torproject.org/torproject.org amd64 InRelease

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Err:15 https://deb.torproject.org/torproject.org amd64 Release

  Certificate verification failed: The certificate is NOT trusted.
The certificate chain uses expired certificate.  Could not
handshake: Error in the certificate verification. [IP:
95.216.163.36 443]

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Ign:9 http://deb.torproject.org/torproject.org trusty/main Sources

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 http://deb.torproject.org/torproject.org trusty/main
Translation-en

Ign:13 http://deb.torproject.org/torproject.org trusty/main
Translation-en_US

Err:9 http://deb.torproject.org/torproject.org trusty/main Sources

  404  Not Found [IP: 116.202.120.166 80]

Ign:10 http://deb.torproject.org/torproject.org trusty/main all
Packages

Ign:11 http://deb.torproject.org/torproject.org trusty/main amd64
Packages

Ign:12 

Re: [tor-relays] Newbie needs help

2022-03-22 Thread tor admin via tor-relays
Tor project recommends 16Mbits/s in each direction minimum 
 so you 
should be fine.


However note the concurrent connections requirement, which can 
"overwhelm consumer-level routers."   That might be something to watch.



On 3/22/22 09:11, tdu...@palmettoshopper.com wrote:

I think I figured it out. Seems DirPort was commented out.

I am getting a warning that my contact info isn't set. I uncommented that
section and put a name and email address. Also uncommented the Nickname.
Still getting the warning.

Just curious, what are the bandwidth requirements to be a bridge? I'm on a
'consumer router' and have around 400 Mbs u/l and 200 Mbs d/l

TIA

-Original Message-
From: tor-relays  On Behalf Of
tdu...@palmettoshopper.com
Sent: Monday, March 21, 2022 5:55 PM
To:tor-relays@lists.torproject.org
Subject: [tor-relays] Newbie needs help

Hi,

Thanks for adding me to the list.

I setup a Tor Relay in Docker using this image:
https://hub.docker.com/r/doudou34/tor-server

Its running, so how can I test it? When I try to access it using port 9001,
I'm unable to connect. I have opened the port on my firewall to the public.
Haven't done it on my router yet but I have Portainer running in Docker and
have no problem accessing it.

Not a lot of instructions that I can find. I can post the torrc file but
it's the same as the one on the docker page.

### /etc/torrc ###
# see /etc/torrc/torrc.default and
https://www.torproject.org/docs/tor-manual.html.en

# Server's public IP Address (usually automatic) #Address 10.10.10.10

# Port to advertise for incoming Tor connections.
# common ports are 9001, 443
ORPort 9001

# Mirror directory information for others (optional) # common ports are
9030, 80 #DirPort 9030

# Run as a relay only (not as an exit node)
ExitPolicy reject *:* # no exits allowed

# Set limits
#RelayBandwidthRate 1024 KB   # Throttle traffic to
#RelayBandwidthBurst 2048 KB  # But allow bursts up to
#MaxMemInQueues 512 MB# Limit Memory usage to

# Run Tor as obfuscated bridge
#ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed
#ServerTransportListenAddr obfs3  0.0.0.0:5 #BridgeRelay 1

# Run Tor only as a server (no local applications) SocksPort 0

# Run Tor as a regular user (do not change this) User debian-tor
DataDirectory /var/lib/tor

# If no Nickname or ContactInfo is set, docker-entrypoint will use # the
environment variables to add Nickname/ContactInfo here
#Nickname Tor4 # only use letters and numbers
#contactinfoem...@example.org

I've only been using docker for a few days, so maybe its an issue there.

TIA

___
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 mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays