it tag --contains c4208ef65f58836670dab286bad0289259582124
tor-0.2.9.1-alpha
So it's just 'moria1'.
[1] https://trac.torproject.org/projects/tor/ticket/18624
[2]
https://gitweb.torproject.org/tor.git/commit/?id=c4208ef65f58836670dab286bad0289259582124
--
Ivan Markin
__
ionoo.git/tree/INSTALL#n44
[3]
https://geolite.maxmind.com/download/geoip/database/GeoLite2-City-CSV.zip
[4] https://trac.torproject.org/projects/tor/ticket/19437
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.t
bsolutely different system (E.g. tor user was
`debian-tor` and it's `_tor` on the new one. Also different locations,
like Windows/Darwin/BSDs/Linux).
Asking for comments before creating a ticket since this idea can be
inherently wrong.
Thanks,
--
Ivan Markin
___
tor' binary should be enough. You can keep default torrc if you want.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
David Goulet:
> Not possible to "include" sub torrc files unfortunately.
One surely can do mkfifo + cat.
P.S. Ha-ha.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman
Ivan Semenov:
> Hello, can I get some vanilla bridges pls
Go to https://bridges.torproject.org/ and select 'none' as Pluggable
Transport. Voila.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torpr
ty of setting
"peering policy". If this would be implemented one can restrict
connections only to relays in consensus (but not bridges?).
[1] https://trac.torproject.org/projects/tor/ticket/19625
--
Ivan Markin
___
tor-relays m
to endanger
users by running a Guard relay there.
Just a guess.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
7;s in some
independent/modified implementation.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
OUS cell to the same relay with the
same cookie.
Most likely it's behavior of some alternative/modified tor
implementation (since it started recently and at almost the same time?).
At least I can't find a way little-t-tor is able to do this.
--
Ivan Markin
__
t's client(s) [hopefully not little-t-tor one(s)] who send
such cells. Thanks everybody reporting about this issue!
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
t
of memory while parsing consensus. See this discussion [1].
[1] https://lists.torproject.org/pipermail/tor-dev/2016-May/010973.html
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/l
]
https://github.com/nogoegst/scan_tor_rfc5961/blob/master/scan_archive/nov17_2016/combined_results.csv
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
2σ of the network. ;(
Please run more different (e.g. BSD) relays!
[*] I think it should be more accurate.
[1] https://github.com/nogoegst/grill
[2] https://gist.github.com/nogoegst/d2de330b794b47158b4cfbed0987b4de
--
Happy life without suffering,
Ivan Markin
__
e tip! Laziness just took over me then.
It turns out that vulnerable consensus weight fraction is 0.249602 or 25%.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
ow ~10-15%.]
Also, you saying "guard discovery attack based on pure off-path TCP
attack" make this *slightly* obvious. So if someone actually got it,
it's likely that they're already exploiting it.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tors
> if any of them have found Challenge ACK counter values higher than
> a million... which would indicate some kind of funny business.
It may not indicate this. Since I was able to scan whole Tor network in
just 7 minutes (someone can use more than 127 concurrent scans and scan
ev
options. See logs
> for details.**
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
7; of relay (see e.g. 'Liberian' relay [2]).
[1] https://trac.torproject.org/projects/tor/ticket/19437
[2]
https://atlas.torproject.org/#details/BC630CBBB518BE7E9F4E09712AB0269E9DC7D626
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.t
re is an awesome The Tor BSD Diversity Project. The
instructions for BSD beginners can be found here [1].
[1] https://torbsd.github.io/relay-guides.html
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject
n number of sent RSTs, probably rate-limited
Current (these) definitions are here [1]. But they are a subject of
change, because I'm trying to improve scanning method (separating
counters for each of bursts).
[1] https://github.com/nogoegst/grill/blob/master/verdict
1 circuit (not client ones) per TLS connection if a
relay joined the network recently
o one has ~7100 [number of relays] TLS connections if their relay
is up for quite some time
o TLS connection is not going to terminate if no circuits left on it*
[*] I may be wrong about it. It holds true
hich
contains long-term relay private key and edited only torrc (nickname,
ports, whatever). Try to clear DataDirectory out and restart tor - it
should regenerate the keys.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https
pushed out from consensus.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
on!
Though I can't see how do these two intersect. What is a path for TLS to
close in "a few minutes if there is no traffic"?
If there is no traffic (no circuits) on top of a TLS connection it still
can be used in next 7 days, right?
--
Ivan Markin
___
Pascal Terjan:
> I would suggest running tor --verify-config as debian-tor user
> instead of root
I would suggest not running tor as root . :)
As root you can do:
su debian-tor "tor --verify-config"
--
Ivan Markin
___
tor-relays
ting shell should "fix" this:
su debian-tor -s /bin/sh -c "tor --verify-config"
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
these rules for Anonymizing Middlebox (though on modern
OpenBSD) quite some time ago and it seemed to work fine. These should
not only work locally - it's for entire LAN. Are these ones you tried?
--
Ivan Markin
___
tor-relays mailing list
tor-relays
n how to deal with config updates.
Please drop a hint here if you succeeded!
* This never happened to me on many systems as they have some sort of
config management.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.
s/25284119/how-can-i-check-if-openssl-is-support-use-the-intel-aes-ni
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
ersions.
You will not see anything in logs until this value isn't good and was
adjusted by tor. For details, see compute_real_max_mem_in_queues()
function in /src/or/config.c.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lis
of recent
discussion about Intel ME and just because Tor needs diversity on all
levels. :)
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
ctivity, etc, etc.
If you think that your relay is underrated or has poor performance try
to adjust your hardware/settings. Anyway almost every relay operator has
this kind of "operator anxiety". Don't worry. ;)
--
Ivan Markin
___
tor-relay
not so technically.
If you have modern ARM then you have NEON so ChaCha20 should be better
that AES. That said slow relays may become a bit faster.
Location diversity as self-hosting is another argument (recall tons of
OVH VPS relays).
Some best practice
rn] Cannot make an outgoing connection without a
> DirPort.
This is probably a bug. Try to switch log level to "info" - tor should
provide a more detailed backtrace saying something like "Address came
from...". Please don't forget to sanitize log
number of connections on your relay (maybe I'm wrong)?
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
there is data; monthly and
> yearly charts showing up quite well):
> Sorry, if this is my local issue but I just can't find the reason for
> it...
Not just you. This data is gone. Though Atlas still 'plots' it.
See https://trac.torpro
nce of
hitting rate-limits (likely RAM usage).
Probably there is a memory leakage somewhere that makes everything fail
and get process eventually killed by OS.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
resume them. In such case tor will regard this
sleep/resume in the main loop as a "clock jump" thus breaking all
circuits. This is because it produces ticks each second in the same
thread as the main loop (which is blocking awaiting for data on a socket).
Ther
definitely ought to be fixed since it
may be a DoS vulnerability (process crash).
So if you have some details on this issue please report them to the
mentioned ticket.
Thanks,
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
descriptor-ids for the future N days for onion address M (for the
> pre-prop224 world).
FYI https://gist.github.com/nogoegst/895dde228496e04f409fc6d160a5de5a
$ go run onion-desc-advance.go -time 1488288001 yrcfcqhja2ide7yh
prints descriptor IDs for the given time for replica #1 and #2.
HTH
--
the 3 HSDirs next to it (by sorted fingerprint).
tldr: HSDir != IntroPoint.
Introduction points are chosen by random by an onion service and unknown
in advance. What is known in advance is only the onion address. Descriptor ID
determines which HSDirs are responsible for storing correspondin
le { 0.0.0.0 }
block in quick on egress from to any
block out quick on egress from any to
}}}
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
here something else?
[1] https://trac.torproject.org/projects/tor/ticket/19625
Thanks,
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
orously (see #19625)
and we should stick with things that we know for sure.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
And it's for
a reason, e.g. one can get into a legal trouble for running an Exit node
in some countries but everything is fine without exiting there.
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
er-descriptors
>
> Could this be a bug in Atlas?
Nope, Onionoo returns the same platform line [1].
[1]
https://onionoo.torproject.org/details?lookup=7A9A7CD200D288DD7D78542779DE16070BC8BFFD
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.
e
not manifested for Win8.1 or Win10 and detect Win10 as 6.2 (Win8).
[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx
[2] https://gitweb.torproject.org/tor.git/tree/src/common/compat.c#n2711
--
Ivan Markin
___
tor-r
48 matches
Mail list logo
