Hello dear relay and bridge hosts,
recently a paper was published, describing a traffic confirmation attack called
DeepCorr, which works against Tor users and as such, also hidden services.
The attack allegedly had success rates of up to 96% percent.
It is being worked on and listed here as a s
penalty for a dubious and poorly understood
>
> privacy gain
>
> https://lists.torproject.org/pipermail/tor-relays/2021-February/019370.html
>
>
> I personally leave my bridges as they are, without iat_mode.
>
>
> Best,
>
> Fran
>
>
>
Regarding web-servers hosting Tor relays, it is much more likely for them to
sit behind a CDN such as Cloudflare for DoS protection and delivery
optimization.
Other services of course, however..
--- Original Message ---
xmrk2 via tor-relays schrieb am Sonntag, 11.
Juni 2023 um 1:46 nac
This is to be expected, you get 100kB/s with iat-mode=2, and around
256-1024kB/s with iat-mode=1, however since most sites I load are just HTML/CSS
with little pictures, it is no big issue.
I would consider taking the speed penalty for more protection (as a research
paper also pointed out).
Gr
Hi,
while going through journalctl I noticed the following entries from my exit
relay and wanted to report this non-fatal assertion.
I also host a Guard relay on the same VM and IP, and it did not yet assert that
message.
The full assert() with the stack-trace is as follows:
> Dec 14 16:29:3
Hello Likogan (you did not specify a name, so I just took your domain name).
First, lets look at issue number one:
If your Tor Exit is using ~50% of the entire CPU (VM or dedicated server?)
while only routing 6 Mbps, then you are likely not using hardware AES
acceleration (aesni).
For example,
Please read the code, not only Tor's code, but also OpenSSL's code.
Yes, AES is not displayed as engine itself, however, it still does not seem to
use aes-ni instructions unless told to initialize engines via the code I
deducted.
If this proves anything, I ran an Exit Relay in 2013 before my ho
Hi Dan,
>1 - Is it better for the network if the relay is active 24/7, even if
>sometimes it's much slower?
Generally according to the relay requirements a relay is considered useful if
it can at least route 2MB/s or 16 MBit/s steadily.
However, I think you should get away with 1MB/s or 8 MBit
have any
security, performance or privacy implications, then please maybe just make it a
harmless information message.
Regards,
George
On Monday, December 18th, 2023 at 11:12 AM, trinity pointard
trinity.point...@gmail.com wrote:
> Hi,
>
> this looks related to TROVE-2023-007 /
&g
option.
>
> I'll probably remove all limits for January and just see how much traffic
> gets transferred.
>
> ---
> Thanks,
> Dan
>
> On Thursday, December 21st, 2023 at 8:04 AM, George Hartley via tor-relays
> tor-relays@lists.torproject.org wrote:
>
>
- Is it possible to immediately remove my relay from relay search on Tor
Metrics?
No.
- If not, when will my relay be removed from the relay list?
Generally 7 days after your relay last uploaded it's descriptor.
Happy holidays,
George
On Sunday, December 24th, 2023 at 11:10 AM, n
7 d a y s.
On Monday, January 8th, 2024 at 9:54 AM, 0tpcqovw--- via tor-relays
wrote:
> I think it's after 30 days it gets automatically removed.
> Malcolm
>
>
> On Mon, Dec 25, 2023, 15:25 nemeto via tor-relays
> wrote:
>
> > DuckDuckGo did not detect any trackers.
> >
> > Hi,
> >
Dear Jeff Blum,
> Yes, I am seeing something similar on 0.4.8.9 (and potentially earlier
> versions as well, not 100% sure when it started). I upgraded to 0.4.8.10
> today hoping it would go away, but I'm seeing it again. Watching in nyx
> (screenshot of bandwidth graph attached), reliably eve
Also,
it should not nearly be as frequent, it happens maybe every 30-45 minutes on my
two relays (one guard, one exit).
Try running Tor natively (you can just move it to a native Linux installation,
by preserving the "`keys/ed25519_master_id_secret_key`" and
`"keys/secret_id_key`" in your Tor
Hello,
for about 3 months I have been hosting two Tor relays:
https://metrics.torproject.org/rs.html#details/AF42E6C77196A37F041A1A1E953E51B4656BDC1B
https://metrics.torproject.org/rs.html#details/7F7D1A5BE88FA7C9358955705AE7AFA61EEDA2B0
After doing system maintenance (mainly upgrading pack
)
Everything else seems fixed.
Regards,
George
On Thursday, January 11th, 2024 at 2:18 AM, George Hartley via tor-relays
wrote:
> Hello,
>
> for about 3 months I have been hosting two Tor relays:
>
> https://metrics.torproject.org/rs.html#details/AF42E6C77196A37F041A1A1E9
Hi,
I think this started with release 0.4.8.10, but both of my Tor relays no longer
reload their config when doing for example:
- systemctl reload tor@exit
Here is the relevant part of the unit file:
> [Unit]Description=Anonymizing overlay network for TCP
> After=syslog.target network.tar
Hey there,
Debian offers unattended upgrades for specific packages:
https://wiki.debian.org/UnattendedUpgrades
If you follow this sites instructions carefully, then you don't have to worry
about updating Tor manually anymore (but you would want to if there is a
significant security issue that
I would definitely want to be able to change my exit policy by just sending a
simple "kill -SIGHUP $pid".
So yeah, consider myself interested in this functionality.
But, don't we already have that implemented?
I remember changing my exit policy then doing "systemctl reload tor" and after
a few
> I also don't like the idea of using exit servers as entrances to Tor.
But you do realize that Tor exits also receive the Guard flag, and Guard
probability assigned?
Check my server:
https://metrics.torproject.org/rs.html#details/0F8538398C61ECBE83F595E3716F7CE7E4C77B21
It mostly acts as an
4th, 2024 at 12:30 AM, li...@for-privacy.net
wrote:
> On Dienstag, 30. Juli 2024 18:34:44 CEST George Hartley via tor-relays wrote:
>
> > I would definitely want to be able to change my exit policy by just sending
> > a simple "kill -SIGHUP $pid".
> >
>
ust 2024 14:30:27 CEST George Hartley via tor-relays wrote:
>
> > This is already impossible, as both circuit and concurrent connection DoS
> > both gets detected and the IP in question flagged and blacklisted.
>
>
> No.
> DoS has been a topic of conversation at nearly
d, 0 INTRODUCE2 rejected.
Thank you,
George
On Friday, August 9th, 2024 at 8:59 PM, boldsuck li...@for-privacy.net wrote:
> On Mittwoch, 7. August 2024 14:30:27 CEST George Hartley via tor-relays wrote:
>
> > This is already impossible, as both circuit and concurrent connection DoS
only useful on exit nodes, and is roughly the
> equivalent to running the right tcpkill incantation to kill all
> already established connection to ip/ports not allowed a new
> ExitPolicy (but that were allowed when these connections were
> initiated).
>
> On Sat, 10 Au
Can this get some attention please?
A temporary fix seems to be to either patch the two magic constants of
MIN/MAX_THREADS mentioned in the bugtracker, or to not use the seccomp syscall
sandbox.
Both not obviously not the best options.
Regards,
George
On Saturday, January 13th, 2024 at 6:29 PM
If there is DoS on bridges on domestic connections, or connections with very
low throughput, then handling (D)DoS at an application layer becomes futile -
it will simply overload the NIC.
But for bridges on at least 100MbE ports, this would be a nice addition.
On Sunday, August 11th, 2024 at 9:
Hello,
> Similar to Briar, even developers of such clients above tell the loss of
> messages and low reliability of the hidden to hidden path. Some of you might
> know, that there were use cases with missing messages in a range of 35-45 %.
Sorry, but this is just not the case from my experie
ds to put on the line for it to drop or get null-routed
automatically.
On Wednesday, August 14th, 2024 at 3:47 PM, George Hartley via tor-relays
wrote:
> If there is DoS on bridges on domestic connections, or connections with very
> low throughput, then handling (D)DoS at an application la
I just typed up a huge reply and it did not get saved for some reason.
Okay, let's do it this way then:
1.) I don't think we need to re-invent the wheel, (q)Tox can be used over Tor,
that is likely one of the messengers you mentioned.
2.) I am currently not receiving the medication I really need
e three clients, there is no
> offence and in the opposite it is a gift to have a common sense how to
> implement groupchat and offline chat and also to have with a Reflec.Tor a
> Server already provided by Tor-Developers. As said, ieven f five or more
> exit-operators alr
Hey,
this should help you out:
https://blog.torproject.org/lifecycle-of-a-new-relay/
Sincerely,
George
On Monday, August 19th, 2024 at 8:01 PM, observatory123 via tor-relays
wrote:
> Dear fellow relay operators,
>
> I've been hosting a tor relay on a VPS (strato) for a couple days now. I'v
Hi,
don't worry, a relay will be removed from metrics 7 days after you shut it down.
Sincerely,
George
On Sunday, August 18th, 2024 at 8:49 AM, kop kop wrote:
> Good afternoon. how can I delete an entry in
> https://metrics.torproject.org/rs.html#search/134
> about fargo node?
> I didn’t thin
It would be a shame if all your nodes would go offline, I live in Germany and
while raids were more common 10 years ago, it's sad to hear that this still
happens to this date.
Ultimately, it just shows how illiterate the police is about the
Telemediengesetz.
Do you run these nodes at home using
Yes, you can do this, you need to back up the following two files:
> secret_id_key
> ed25519_master_id_secret_key
But the problem I think is that while you can move your node, the old IP and
port is still hardcoded into the Tor codebase.
-GH
On Thursday, October 3rd, 2024 at 9:24 PM, boldsuck
-GH
On Sunday, October 6th, 2024 at 7:35 PM, boldsuck via tor-relays
wrote:
> On Saturday, 5 October 2024 00:40 George Hartley via tor-relays wrote:
>
> > You should default to full disk / partition encryption.
>
>
> Apart from that FDE is not recommended, especiall
03 13:06, boldsuck via tor-relays wrote:
>
> On Wednesday, 2 October 2024 21:24 Sebastian Hahn wrote: On 2. Oct 2024, at
> 09:05, George Hartley via tor-relays wrote:
> It could be that your provider has throttled you temporarily. I don't think
> so, I get that message on a d
No problem.
You should default to full disk / partition encryption.
The ArchLinux Wiki has (as usual) a great article on this:
https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#Encrypting_devices_with_cryptsetup
Also make sure to not use the standard hash library (SHA256) but SHA512
If you are a contributor, maybe mention to staff / security where you want to
go?
Were you on a / the guests list (it sounds like it)?
I really doubt that they would deny you entry if the event just started, maybe
be a bit more persistent, and if you know someone inside, call them to get them
Hello,
I noticed this same behavior, but from my exit relay instead, so I now reject
port 22 exits.
It would be helpful if there was a way to allow SSH, while being able to
control IP-Range scanning and brute-force attacks.
For example:
If a circuit by a client with malicious intent (IP-Range
Taking some answers from a reply to a different user:
The BCM2712 SoC microcontroller has a base frequency 1,5 GhZ with 4 cores and 4
threads, but most importantly, it also supports openSSL hardware acceleration,
with up to 42 times faster AES speeds.
Also, regarding the "I'll just do this at h
Hello,
I do operate an exit node which rejects exits on port 22.
You should, by default, change your SSH port to a random 5 digit number:
Random.org Random Number Generator
And apply static IPTables rules to block connection spam even if someone
portscans your system (make sure to apply this r
Hey Keifer,
the CPU is very capable for the price asked for the whole system (35 bucks).
I think you would be able to squeeze maybe 100 MBit/s out of the mostly
single-threaded Tor instance but that's it.
If you just want your own little private bridge or a small guard relay, go for
it but if
Hello, here is a 20 minute tcpdump using the PCAP format.
There were only 19 packets inbound on port 22 during said time:
Interestingly, my server was communicating with some other server, making
connections TO port 22..
I then looked up said IP in Metrics, and it was just as I assumed another
Hello dear MPAN,
thank you for being so detailed with all the trace-routes.
Seems like your upstream provider is blocking traffic to:
moria1
gabelmoo
longclaw
faravahar
This should never happen, can you contact your provider, and the last online
servers e-mail address (just WHOIS the IP-Addres
Hi,
the node is back online.
Everything works normally, and I don't get any bogus SSH packets when using
iptraf-ng.
Also, we noticed reverse path filtering was off on the VM.. we enabled it. but
don't know why it was off.. I configured the ArchLinux VM's /etc/sysctl.d
entries on my own, and i
Hello, add me to the list too.
Started receiving packets 3 days ago and Tor Weather sent me an e-mail
regarding it.
Sad that I could not respond further.. I try to maintain an extremely high
uptime. So far, the node has only been been offline for 6 hours in 6 months..
now it's been 72 hours :(
Hey, I took a look at their boards and the AML-A311D-CC SBC looked like a great
choice.
6 cores total, 4x ARM-73, 2x ARM-53 which also feature the crypto extensions.
Said crypto roviding up to 40x more speed decoding / encoding AES which is
great for openssl (and by extension, thus also Tor).
Hi, my relay is showing no abnormal logs, publishes it's descriptor just fine
and shows on Atlas / Metrics.
Thank you for the heads up though!
-GH
On Tuesday, October 22nd, 2024 at 10:48 AM, Roger Dingledine
wrote:
> Hi folks!
>
> We're hunting down a mystery where two of our big universit
Whenever my exit node gets a guard probability percentage > 0, then I see this
happen as well.
I always thought that it is just clients using the exit as a Guard, so it now
receives 3x encrypted packets from the clients, decrypts the packet, and
forwards it, causing more Rx than Tx in bandwidth
Hello Tor community,
this e-mail applies to you if you are running an obfs4 (now known under the
name lyrebird) bridge or want to do so in the future.
Some recent posts on this list has shown that traffic timing analysis can be
used to locate a users or onion services guard nodes or bridges. Th
>From my experience, it should come back online, but not instantly - you likely
>need to wait for the next descriptor to be uploaded (once every 6 hours
>usually).
All the best,
George
On Wednesday, September 25th, 2024 at 12:53 PM, Tor Relay Net Ops via
tor-relays wrote:
> Greetings fellow r
Hello,
I don't see how this is an issue, because Tor guards / middles only ever relay
traffic, and exits already have sufficient REJECT rules:
> reject 0.0.0.0/8:*
> reject 169.254.0.0/16:*
> reject 127.0.0.0/8:*
> reject 192.168.0.0/16:*
> reject 10.0.0.0/8:*
> reject 172.16.0.0/12:*
I am jus
Hi, looks like the DirAuth's think that your relay is unreachable, and so your
descriptor isn't published, so your flags are not updated, this would explain
the lack of change in flags.
Port 443 on 156.67.111.146 is open for me, can't test IPv6 as I have disabled
it through my modem and kernel
Hi Roger,
> There is a fine policy question here, which is "ok so what now? Do we leave
> them in place or bump them out of the network?"
This is just my experience, but reaching single node operators has become
notoriously difficult - I frequently use metrics to find out-of-date /
potentiall
l instructions on what clients should configure
> and what servers should configure.
>
> Not official yet, I've been hiding the OrPort for bridges for a year now.
> https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129
>
> > On 23/09/2024 12:15, George Hartley
> It could be that your provider has throttled you temporarily.
I don't think so, I get that message on a dedicated 10 GbE link with little to
no use except for the exit relay on it.
Also, if his relay publishes it's descriptor, then why Metrics won't reflect
that?
It should show it as online
> but the packets are injected into the Internet from another location entirely.
On that note, most data-centers nowadays have routers do SRC IP checks, and do
not allow the traffic through if it doesn't match that interfaces assigned
address.. it would probably more useful to somehow find the
Hey,
my personal experience with OVH was that they would accept 5-10 abuse reports
per day, even if you replied to them, and then replied to the abuse report with
the forwarded reply, but they always disable your VM/Server after 21-30 days.
OVH is also on the GoodBadHosters community page.
-GH
Does your server CPU support hardware AES extensions?
Run this command in your shell (bash most likely):
lscpu | grep aes
If it returns the string AES, then you can make use of the crypto hardware
acceleration.
This severely reduces CPU usage by Tor.
Also, if you want to reduce CPU usage furt
Thank you for helping out repressed people see the open, uncensored Internet
for the first time.
Is there any specific reason why you chose to quit beside age reasons?
Unfortunately, I was forced to shut down my 100 MbE Exit Relay just one week
ago.
Maybe I can continue the legacy?
My old rel
7.0.0.1:9090 NoAdvertise
> ## If you want to listen on IPv6 your numeric address must be explicitly
> ## between square brackets as follows. You must also listen on IPv4.
> #ORPort [2001:DB8::1]:9050
Good luck with everything.
-GH
On Tuesday, December 17th, 2024 at 2:42 AM, Red Oaive
Hello dear list readers and contributors,
We received UDP floods (mostly through DNS Amplification) which were usually
60-70 GBit/s in size, up until a month ago this was not a problem for most of
the exit relays lifetime, because we had a custom Tilera sitting between our
server and the remain
On Friday, February 7th, 2025 at 12:22 PM, George Hartley via tor-relays
wrote:
> Hi there "usetor",
>
> I am going to answer a few of your questions:
>
>
> 1. "If a full IPv4 /24 Class C was available to host Tor relays, what are
> some optimal ways
Sorry for the late reply, but at least on ArchLinux, Tor already comes with a
service file for systemd and an example configuration file at
> /etc/tor/torrc
To make Tor auto-start on system boot, use:
> systemctl enable tor
systemd also offers variable sandboxing mechanisms, which should be
Hi,
it seems that your address is not reachable for me:
>From fe80::6e62:6dff:fe85:b8f9 icmp_seq=1 Destination unreachable: Address
>unreachable
>From fe80::6e62:6dff:fe85:b8f9 icmp_seq=2 Destination unreachable: Address
>unreachable
>From fe80::6e62:6dff:fe85:b8f9 icmp_seq=3 Destination unreac
Hi,
sorry for the late reply, I was busy working.
The only thing that stands out to me immediately is that you configured two
separate ControlPort authentication methods:
> HashedControlPassword
> XX:XX
> CookieAuthentication 1
You m
Hello,
you will encounter this, Guard node, middle node, or exit node.
If a website operator is going to blacklist all relays, then you will not be
able to connect to their site, simple as.
Also, we need any kind of clean node - especially exit nodes, but also any type
of other good (high upt
Hello,
this is weird indeed, but the packet size is interesting.
For example, using the tool MTR, you can trace the route to another host using
different protocols:
1.) ICMP being the obvious default.
2.) TCP.
3.) UDP.
If all these TCP packets were just below 100 bytes, that would be my guess.
Hi,
when reading that, this was my suspicion as well.
Ask your provider if the port is shared between other customers (common
practice for virtual servers, for example I used to have one with a port speed
of 100MbE, in the Czech Republic, however the port was sharted 1:3, so there
were always
Hey there,
to efficiently help you, could you please post your /etc/tor/torrc?
Otherwise, the relays that you see in Russia are likely on a host that does not
enforce the ban of the Tor Project.
However, your nyx data is quite weird.
Did you run it as the Tor user?
- sudo -u tor nyx
Othe
Hi there "usetor",
I am going to answer a few of your questions:
1. "If a full IPv4 /24 Class C was available to host Tor relays, what are some
optimal ways to allocate bandwidth, CPU cores and RAM to maximize utilization
of the IPv4 /24 for Tor?"
With 2 IPv4 addreses per relay as a hard limi
I was at work when writing that e-mail,
> > i.e. under time pressure.
> >
> > I hope I could help you anyway.
> >
> > Best Regards,
> > -GH
> > On Friday, February 7th, 2025 at 12:22 PM, George Hartley via tor-relays
> > wrote:
> >
>
I have to disagree with this statement by "m...@nothingtohide.nl":
- - only run middle relays on very high clocked CPUs (4-5 Ghz).
Using hardware AES acceleration, older CPU's are fine.
For example, you can get Xeon E3-1231 v3 server CPU's (LGA1150) for around
$9,99 a piece, and they run at
73 matches
Mail list logo
