s should have their own
dedicated (intermediate/flow-through?) 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-rela
Donncha O'Cearbhaill:
> Thanks everyone for all the feedback I've received about OnionTip. It
> was originally created in a rush during a hackathon so there is
> definitely room for improvement.
>
> Mike Perry, as Mike Cardwell has said, it is currently possible to
>
/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/tor-relays
ot need 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=get&search=0x29846B3C683686CC
--
Mike Perry
c identity fingerprints
and prices to do 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
sign
I run 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 wrote:
> >
> > Moritz Bartl:
> >> Prices vary widely across different countries. We pay between $400
showing donations received to my
> > address:
> > http://blockchain.info/address/1GXZVChXoxgrBzqMsCrWGu2ua6VTKSH6U1
> >
> >> My concern (which has been highlighted before by Mike Perry) is
> >> that the site lacks accountability and transparency. There is no
> &g
we think we want to encourage in the
network. If we get an idea as to if Exits are actually more expensive to
run than non-Exits, we can use that to guide these bonuses.
Thanks a lot for OnionTip! It's now got my vote for inclusion on the Tor
donations page!
> On Sun, 2014-09-28 at 02:32 -
substantiated, 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
signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
vailable, but they were Tor-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@lis
ting a much more comprehensive blog post; it
> >will be filled with gory technical details AND it will include
> >information on how to use HoneyBadger. HoneyBadger has optional (off
> >by default) full-take logging which could enable you to capture a
> >zero-day payload from
yMjMzOSxcInZcIjoxLFwidXJsXCI6XCJodHRwOlxcXC9cXFwvYmFja3N0YWdlLnNpdGU1LmNvbVwiLFwiaWRcIjpcIjEwOTljMmE1MWVkMDQ5YjViMzkxZDVjODA1ZTNhOTM1XCIsXCJ1cmxfaWRzXCI6W1wiZjkzNjUxMGE2YWRmNTJlZDkxNjU3NTg2YjU2YzViMWZiY2E3ODYzMVwiXX0ifQ>
> | Service Notices
> <http://mandrillapp.com/track/click/14822339/forums.site5.com?p=eyJzIjoiOG95VEtHWXlMRl9CUlVmRzVBV1R6VFR3RHMwIiwidiI6MSwicCI6IntcInVcIjoxNDgyMjMzOSxcInZcIjoxLFwidXJsXCI6XCJodHRwOlxcXC9cXFwvZm9ydW1zLnNpdGU1LmNvbVxcXC9mb3J1bWRpc3BsYXkucGhwP2Y9NFwiLFwiaWRcIjpcIjEwOTljMmE1MWVkMDQ5YjViMzkxZ
d not spam. Has anyone experienced any abuse
from these ports that involved non-authenticated mail/spam?
Otherwise, it seems that exit operators who were using the reduced exit
policy should consider updating their polices to include these ports.
--
Mike Perry
signature.asc
Description: Di
s still going to be "OMG Tor is like SO UNUSABLY SLOW!!"
So long as this keeps happening, I suspect it is unlikely for people to
rush to Tor because it is now faster.
I think once we expect most of the clients to have switched to 1 guard,
we should get some torperf g
ed in these cases would be very useful to inform how we might want
to design padding and connection usage 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
p
grarpamp:
> On Wed, Aug 12, 2015 at 7:45 PM, Mike Perry 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, o
. What makes you think it might?
Well, it seems harder to store a full connection tuple for open until
close, because you have no idea when the connection actually closed
(unless you are recording a tuple for every second during which there is
any activity, or similar).
--
Mike Perry
signatu
grarpamp:
> On Thu, Aug 13, 2015 at 3:40 AM, Mike Perry 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 mig
some standard (if heavy-handed) connection-level
logging policy.
I suspect that type 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 oth
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 o
grarpamp:
> On Thu, Aug 13, 2015 at 3:40 AM, Mike Perry 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
grarpamp:
> On Fri, Aug 21, 2015 at 12:30 AM, Mike Perry 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 add
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.
--
Mike Perry
signature.asc
Description: Digita
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
have to curtail exit access to HotMail. Yeah, it sucks, but I know of
> no way to block the sending of webmail while still allowing it to be
> retrieved.
Make sure this is done via exit policy and not iptables or DNS filter.
Also, are you sure you have the whole hotmail netblock?
--
Mi
that your actual legal responsibility
is zero in most countries, but it might make them feel better that you
acknowledge it will be you proving that in court, not them.
--
Mike Perry
Mad Computer Scientist
fscked.org evil labs
pgpqhUGZ8U6Ao.pgp
Description: PGP signature
__
haps longer if it doesn't 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.
Thus spake Sebastian Urbach (sebast...@urbach.org):
> Am Sat, 3 Dec 2011 18:57:22 -0800
> schrieb Mike Perry :
>
> Hi,
>
> > I've made five major changes to try to address these issues:
> > happens over the next week or so.
>
> Well, somebody has to say it
f web
browser tech for user-generated video still sucks in the absence of
Flash, so it is still not yet our primary focus.
--
Mike Perry
pgpNaqqbt2Axf.pgp
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://li
d to keep an eye on things for a bit longer to be sure, I
suspect.
--
Mike Perry
pgpNDRjUdtLcC.pgp
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
ing into TCP socket exhaustion
on any of your relays? It is a possibility, esp 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
_
Thus spake Mike Perry (mikepe...@torproject.org):
> Thus spake Tim Wilde (twi...@cymru.com):
>
> > > I try to keep everything I do documented on that wiki. All these
> > > servers run four instances of Tor each (one per core) and traffic
> > > is accounted for
ave? Some combos of are pretty abysmal about IRQ load
balancing and interrupt optimizations, or at least they were on old
kernels (which may still apply if you are CentOS).
--
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
erval from 2 weeks to 1
week.
My plan is to let these changes run for another couple days, 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
e bwauths. I also think #4730 is more likely to capture the problem
we were seeing with fast nodes being fast only sometimes, and it will
be way less work.
Thanks for bearing with me, but we still might have a ways to go
before we really get to the bottom of this
other feedback params were set for the duration.
See
https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.spec.txt#l477
for more info on the consensus params that alter bw auth behavior, and
please read the rest of the spec if you're interested in getting
s actually accomplish that?
If so, should we work on providing scripts to make the loopback
filesystem creation process easier, and/or provide loopback images
themselves?
Even the APT defenses end up not working out, I would sleep a lot better
at night if most rela
ur
> suggestions in a section that starts with a paragraph like:
>
> | Here are a couple of things you could do to improve your
> | relay's security some more. Whether or not you consider
> | them worthwhile is up to you and if you decide against some
> | or all of them or if they don't work on your system, your
> | relay is still appreciated.
Ok, yes, I have no intention of making 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 mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thus spake Mike Perry (mikepe...@torproject.org):
> You're failing to see the distinction made between adversaries, which
> was the entire point of the motivating section of the document. Rekeying
> *will* thwart some adversaries.
>
> > I suspect getting the keys through
ompromised exit.
Yes, there are things we can do 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: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
all 5 bw auths are
voting, and I have not changed the algorithms.
--
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
rth paying a premium for, because it does require
more resources at the ISPs end in terms of occasional abuse noise. You
could also try negotiating upwards if your ISP's prices are already
competitive with FDC's for middle service. Something tel
o busy to dig
them up right now). There have also been several equipment seizures in
the EU that never escalated to a court case...
--
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
Thus spake Jon (torance...@gmail.com):
> On Tue, May 22, 2012 at 3:17 PM, Mike Perry wrote:
>
> > > On Tue, 22 May 2012 13:29:54 -0500
> > > Jon allegedly wrote:
> > >
> > > > Yep same here, got notice today from ISP on a report of the 20th for
>
legal opinion on if these things can actually be
arbitrarily coercive in nature. "Give me your key. Also, keep using it.
Also, tell your mother you hate her and wish she was dead."
Does the madness ever end?
--
Mike Perry
signature.asc
Description: Digital signature
_
s to divide by the total uptime of the
relay?
Does SIGHUP clear them? Can they get cleared in other sitations?
--
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
cus 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
Thus spake Nils Vogels (bacardic...@gmail.com):
> On Tue, Jul 24, 2012 at 9:17 AM, Mike Perry wrote:
>
> > Thus spake k...@damnfbi.tk (k...@damnfbi.tk):
> >
> > > Hey all,
> > > Have you contemplated sending this over to the hackerspaces list?
> >
> &
5.2% 8333: 1.1% other: 0.5% 8080: 0.1% 995: 0.0%
Misc 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
si
Thus spake Steve Snyder (swsny...@snydernet.net):
> On Wednesday, August 15, 2012 4:44pm, "Mike Perry"
> said:
> > Here's the read and write statistics from the ExtraInfo descriptors
> > from a handful of the fastest default-policy and reduced-policy
> >
ion Gmail has hated on account creation
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
st of the abuse mail you'll get will be
due to 80 and 443 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 P
ypothesis is right I ask owners of Exit-nodes, if it
> possible, to let that port in their ExitPolicies.
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.
Th
rspec.git. Fixes bug 8965.
>
> o Code simplification and refactoring:
> - Avoid using character buffers when constructing most directory
> objects: this approach was unwieldy and error-prone. Instead,
> build smartlists of strings, and concatenate them wh
city.
> Would it be able to keep the nickname or would it have to change also?
> Would this have effect on the onion address if I had a hidden server?
No and no, but your hidden server might have brief downtimes/descriptor
publish times that correlate with your key rotation. Not
rg/projects/tor/ticket/7028
Did they shut you down entirely, even forbidding non-exit for some
reason? Or did you decide to move to a new ISP that supports exits?
--
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
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 signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
ally considered poor form to run too much
of the Tor network by yourself until other people can 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 lega
;m also wondering 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
y old key) at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=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
gt;
> > ___ tor-relays mailing
> > list tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> > ___ tor-relays mailing
> > list tor
; ___
> 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
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
not depend much on the amount of traffic,
> >but much more on the number of connections/handshakes.
> >___
> >tor-relays mailing list
> >tor-relays@lists.torproject.org
> >https://lists.torproject.org/cgi-bin/mailman/listinfo/to
like a Tor. As far as I know, we don't provide packages for this
yet, 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#instr
___
> > 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/mai
or."
4. "I rolled my 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
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:
>&
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
earch from 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/O
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
ort the business 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.
directory authorities 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.
Ag
don't think there
> 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
h this info 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-
g issues with 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
can make it such that an attack has to be
"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
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.or
-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
78 matches
Mail list logo
