-operators/relay-bridge-overloaded/
P.S. There is a known warn bug with vanguards-lite on first startup. It
is harmless: https://gitlab.torproject.org/tpo/core/tor/-/issues/40603
--
Mike Perry
___
tor-relays mailing list
tor-relays
On 1/23/22 5:28 PM, s7r wrote:
Mike Perry wrote:
We need better DoS defenses generally :/
Of course we need better defense, DoS is never actually fixed, no matter
what we do. It's just an arms race the way I see it.
Well, I am extremely optimistic about
https://gitlab.torproject.org/tpo
uot;severe" and "ongoing" long enough such that a relay has lost capacity
and/or lost the ability to complete circuits, and that relay can't do
anything about it, that relay unfortunately should not be used as much.
It's not like the circuit will be likely to succeed or be fast enough
ith our attempt at solving it, see:
https://gitlab.torproject.org/tpo/core/tor/-/issues/16255
--
Mike Perry
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
o anymore.
I think this and similar ideas should be explored. We're trying to
figure out how to put it all together into an approach that makes sense.
--
Mike Perry
signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing
re
> is any policy change necessary.
Ok great! Sometimes I am surprised by their decisions, and I didn't see
this one.
--
Mike Perry
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
orities are deliberately independent
from TPI though, and even what I think is not necessarily what TPI
thinks. The dirauths may have different opinions. Coordinating policy of
this nature is difficult and requires consensus building.
Again, I understa
interests of tech oligarchs that believe
that the world should be run by a handful of oligarchical ISPs and email
providers, with government-issued identity for all.
Fuck that.
Good luck, Matt! Thanks for being awesome!
P.S. Your mails ended up in my provider's spam filter. Dug them out for
great j
On 10/5/20 9:15 AM, Georg Koppen wrote:
> Mike Perry:
>> On 10/3/20 6:38 AM, nusenu wrote:
>>>> Me and several tor relay operator friends have questions about
>>>> Malicious Tor exit nodes. How do you define a node as malicious ?
>>>
>>> In
me, and a couple months of proposal review,
with one revision round. Because of these issues on both sides, it has
literally been years since we identified this problem area, and got
funding to act on it.
The good news is we start Monday.
1. https://en.wikipedia.org/wiki/OODA_loop
Roman Mamedov:
>
> On Thu, 05 Sep 2019 02:11:00 +0000
> Mike Perry wrote:
>
>> 1. "I didn't know that Debian's backports repo has latest-stable Tor!"
>
> I only looked to backports when I get a warning on the metrics website that my
> versions are not re
teor:
>> On 5 Sep 2019, at 12:11, Mike Perry wrote:
>>
>> Unfortunately, we still have something like 2500 relays on either Tor
>> 0.2.9-LTS or Tor 0.3.5-LTS.
>>
>> What are the reasons for this? My guess is the top 5 most common
>> responses are:
>&
own custom Tor from git and forgot about it."
5. "My relay machine was not getting any updates at all. Oops."
Does anyone have a reason that they think many other relay operators
also share?
How can we fix that for you, or at least, how can we make it easier to
run the very latest
legitimate content at
some rate. Nobody was using anything more advanced than snort-style
regular expressions that matched things that happened to look like
exploits.
FWIW, I am personally in favor of reinstating such a policy. I doubt the
situation has changed.
--
Mike Perry
signature.asc
D
>
> CPU is Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz.
If this is 14-25 Megabytes/sec per core (and corresponding tor process),
then this is also consistent with what I remember.
Without AES-NI: ~100Mbit per core. With AES-NI: over 300Mbit per core.
grarpamp:
On Fri, Aug 21, 2015 at 12:30 AM, Mike Perry mikepe...@torproject.org wrote:
I submitted a proposal to tor-dev describing a simple defense against
this default configuration:
https://lists.torproject.org/pipermail/tor-dev/2015-August/009326.html
nProbe should be added
grarpamp:
On Thu, Aug 13, 2015 at 3:40 AM, Mike Perry mikepe...@torproject.org wrote:
But consider looking at average flow lifetimes on the internet. There may
be case for going longer, bundling or turfing across a range of ports to
falsely
trigger a record / bloat, packet switching
grarpamp:
On Wed, Aug 12, 2015 at 7:45 PM, Mike Perry mikepe...@torproject.org wrote:
At what resolution is this type of netflow data typically captured?
Are we talking about all connection 5-tuples, bidirectional/total
transfer byte totals, and open and close timestamps, or more (or less
activity, or similar).
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Mike Perry:
grarpamp:
The questions were of a general intro to netflow nature, thus
the links, they and other resource describe all the data fields,
formation of records, timeouts, aggregation, IPFIX extensibility, etc.
Others and I on these lists know what 360 gigs of netflow looks like
of adversary will be possible to defeat with similar
amounts of padding that will defeat hidden service circuit setup
fingerprinting, website traffic fingerprinting, traffic type
classification, and a host of other low-resource attacks...
--
Mike Perry
signature.asc
Description: Digital signature
grarpamp:
On Thu, Aug 13, 2015 at 3:40 AM, Mike Perry mikepe...@torproject.org wrote:
However, Tor still closes the TCP connection after just one
hour of inactivity. What if we kept it open longer?
The exporting host has open flow count limited by memory (RAM).
A longer flow might
against this and other issues.
Information about how UDP is treated would also be useful if/when we
manage to switch to a UDP transport protocol, independent of any
padding.
Thanks a bunch!
--
Mike Perry
signature.asc
Description: Digital signature
think once we expect most of the clients to have switched to 1 guard,
we should get some torperf graphs going for guards of various
capacities, and see what the actual effects of this are.
--
Mike Perry
signature.asc
Description: Digital signature
=eyJzIjoiNk1ITGJJd3NSc2IySGNNQzlmNTkwNXpPUmd3IiwidiI6MSwicCI6IntcInVcIjoxNDgyMjMzOSxcInZcIjoxLFwidXJsXCI6XCJodHRwOlxcXC9cXFwva2Iuc2l0ZTUuY29tXCIsXCJpZFwiOlwiMTA5OWMyYTUxZWQwNDliNWIzOTFkNWM4MDVlM2E5MzVcIixcInVybF9pZHNcIjpbXCI4ZDBlNzhmZWFlNjM5Yjk2MTc2NDdkNzMyOGQyMTBkNzkxZTVjNWExXCJdfSJ9
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
--
Mike Perry
signature.asc
Description: Digital signature
. HoneyBadger has optional (off
by default) full-take logging which could enable you to capture a
zero-day payload from a TCP attack; you should then responsibly
disclose to the software vendor or contact a malware analyst to help
out!
Sincerely,
David Stainton
--
Mike Perry
signature.asc
-friendly.
1. https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
2. http://www.appliedops.net/.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https
, but that seemed premature at this point, too. I suppose it
still may come to that, though, if they keep ignoring us and making
extreme, unsubstantiated, and inaccurate claims, especially with our
trademark and logo plastered on the thing, as if it were an endorsement,
or even our product.
--
Mike Perry
concern (which has been highlighted before by Mike Perry) is
that the site lacks accountability and transparency. There is no
way to verify the donations actually reach the operators.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor
a non-exit relay
there. (Thinking about making it an exit.)
Kees
--
Kees on the move
On 25 Sep 2014, at 03:03, Mike Perry mikepe...@torproject.org wrote:
Moritz Bartl:
Prices vary widely across different countries. We pay between $400 and
$1500 per Gbit/s per month in popular
that calculation first. Again, I want to extrapolate
from real relays, using our current load balancing.
So far only two people have given me identity fingerprints with actual
pricing information. I need way more.
--
Mike Perry
signature.asc
Description: Digital signature
to send this information publicly to the list. I am
happy to receive it privately via GPG. My GPG key id is
0x29846B3C683686CC, and that key signs all of my mail to all torproject
lists. You can get it here:
https://pgp.mit.edu/pks/lookup?op=getsearch=0x29846B3C683686CC
--
Mike Perry
signature.asc
://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
- End forwarded message -
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo
?) BTC address, so it is possible to
perform auditing for each of them using only the blockchain.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin
, but if you are technically inclined, you can set one up manually on
Linux by following these instructions:
https://www.torproject.org/projects/obfsproxy-instructions.html.en#instructions
--
Mike Perry
signature.asc
Description: Digital signature
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
--
Mike Perry
/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
--
Mike Perry
signature.asc
Description: Digital signature
@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
--
Mike Perry
signature.asc
key) at:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x29846B3C683686CC
Here's the fingerprint and current subkey information for reference:
pub 8192R/29846B3C683686CC 2013-09-11
Key fingerprint = C963 C21D 6356 4E2B 10BB 335B 2984 6B3C 6836 86CC
uid Mike Perry
if any aspects of the load has any other relation to
node flags.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
catch up and
balance your efforts. I would look for ways to decentralize/delegate
once you got beyond a couple gbits or so for this reason. Please feel
free to ask the list for suggestions on legal and admin structure for
accomplishing this.
--
Mike Perry
signature.asc
Description: Digital
?
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
get more?
Note that only 1 IP means you can only run 2 Tor instances on that, and
even with AES-NI, each Tor instance probably caps out at about 300Mbit
at most. Without AES-NI, you probably could only push 100-150Mbit per
Tor instance...
--
Mike Perry
signature.asc
Description: Digital
/mailman/listinfo/tor-talk
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
.
Not sure if that's actually the problem, but if the only way you can
get to Skype is to use a Bittorrent-supporting exit, it certainly seems
like a possibility.
Thanks for the heads up James!
--
Mike Perry
signature.asc
Description: Digital signature
anyway. There are also technical reasons to avoid
having 1000 slightly different versions of the reduced exit policy.
Hence the reduced policy allows every app port that we could find in
use, *except* bittorrent.
--
Mike Perry
signature.asc
Description: Digital signature
over Tor for some time now..
If that is still true, it's likely this new abuser uses both Tor and
non-Tor... Thus simply blocking Tor from Usenet (even if we could) as
the abuse complaint demands is unlikely to stop the abuse.
--
Mike Perry
signature.asc
Description: Digital signature
Exit raskin read 670.2M
80: 77.6% 443: 21.2% 8080: 0.3% 563: 0.2% other: 0.2% 81: 0.2%
Misc Exit raskin wrote 30.3M
443: 57.3% 80: 42.1% 8333: 0.3% other: 0.3% 995: 0.0% 8080: 0.0%
--
Mike Perry
signature.asc
Description: Digital signature
Thus spake Steve Snyder (swsny...@snydernet.net):
On Wednesday, August 15, 2012 4:44pm, Mike Perry
mikepe...@torproject.org said:
Here's the read and write statistics from the ExtraInfo descriptors
from a handful of the fastest default-policy and reduced-policy
relays:
Pardon my
on? Announce? Discuss?
Other?
Also, how do we recognize reputable Hackerspaces from Sketchy bunch of
d00dz who think it will be totally awesome fun to pwn a bunch of Tor
users? Should we check for previous reliable Tor relays from them?
Should we just not care?
--
Mike Perry
signature.asc
Description
Thus spake Nils Vogels (bacardic...@gmail.com):
On Tue, Jul 24, 2012 at 9:17 AM, Mike Perry mikepe...@torproject.orgwrote:
Thus spake k...@damnfbi.tk (k...@damnfbi.tk):
Hey all,
Have you contemplated sending this over to the hackerspaces list?
There exists THE list
to defend against these attacks in the
client. See https://trac.torproject.org/projects/tor/ticket/5456 for
some of those. But I think we should also take this opportunity to think
a little deeper about protecting and rotating relay keys in the first
place.
--
Mike Perry
signature.asc
Description
anything mandatory. It's not
really possible anyways, and heterogeneity probably trumps it.
For the paragraphs I've trimmed, assume I more or less agree with your
statements.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-relays
, and if
they don't seem to change anything, I plan to try 1 week on, 1 week
off cycles of the experiment, to see if we can detect any patterns in
exactly when and why torperf starts to go south.
--
Mike Perry
pgpEcEG5ASzOd.pgp
Description: PGP signature
).
--
Mike Perry
pgpZotrS0hGmK.pgp
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
for Guard+Exits with
gobs of CPU and gobs of throughput.
I am curious if we will need to do this or not:
https://trac.torproject.org/projects/tor/ticket/4709
--
Mike Perry
pgp2w2GmofAI1.pgp
Description: PGP signature
___
tor-relays mailing list
tor-relays
explode and seems to improve performance
on https://metrics.torproject.org/performance.html) starting tonight
or tomorrow.
Please keep an eye on your relays and tell us if anything unexpected
happens over the next week or so.
Thanks!
--
Mike Perry
pgpwKXGhGFtO5.pgp
Description: PGP signature
57 matches
Mail list logo
