Re: [tor-relays] MiB/s / metrics

[usprey]

+1 grarpamp

bits with decimal prefixes is the only thing that makes sense in the
networking world.
On 20 Jan 2015 00:09, "grarpamp"  wrote:

> On Mon, Jan 19, 2015 at 5:55 AM, Sebastian Urbach 
> wrote:
> > I opened a ticket recently with the intention to use a more common unit
> than
> > MiB/s for metrics. Karsten basically agrees but is waiting for more
> input.
> >
> > https://trac.torproject.org/projects/tor/ticket/14257
>
> Tor is at its core a network application, an interface to the
> network, a router. In the real ISP world therein everyone speaks
> in "mega bits per second" "10^n" (and now with 100Gbps
> links, in Gbps).
>
> Only the downstream hosting world speaks in "mega bytes"
> "2^n", "per" "whatever time unit they dream up". This comes
> from attempts by hosters to appease people pushing their
> disk files MiB's over the net at link rate, not spread over bandwidth
> rate. In fact, the hosters have to convert that appeasement on their
> backend to aggregated Mbps so they can talk to their real ISP's.
>
> I've suggested before that Tor project should use Mbit/s (or Mbps
> or Mbit[s] where the slash presents a problem) as its primary default
> representation for Tor client and all related projects that refer to
> bandwidth.
> Tor is a bandwidth app, especially at the relay level. There is no disk or
> instantaneous link rate transfer need applying to Tor relay. (As opposed
> to user level which is more of a mashup of rate usage contexts and
> interests similar to bittorrent/webserving.)
>
> Then if people want MiB's or MB's so they can continue perpetuating
> and interfacing with hosters who do the same, you could add a
> few global prefix, unit and time options to switch all representations
> over at once. (Tor client has recently added per stanza Mbps
> configs which is a fine alternative to global. Yet again, the manpage
> and even maybe the code still uses nonsense in regards to capitalization,
> base 2 vs 10, crossed contexts, etc...)
>
> Start here, use the table in the upper right, ignore jedec,
> and pick and apply 10^n or 2^n representations consistantly.
> https://en.wikipedia.org/wiki/Binary_prefix
>
> "
> BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits
>A token bucket limits the average incoming bandwidth usage on
> this
>node to the specified number of bytes per second, and the
> average
>outgoing bandwidth usage to that same value. If you want to run
> a
>relay in the public network, this needs to be at the very least
> 30
>KBytes (that is, 30720 bytes). (Default: 1 GByte)
> Notably, "KBytes" can also be written as "kilobytes" or "kb";
> "
>
> No, "KBytes" is invalid, there is no capital "K", only "k (SI)" and
> "Ki (binary)".
> Nor is "b" ever a byte, nor is "Bit[s]" ever capitalized.
> True network applications should also not be crossing network-like prefixes
> with disk-like objects or vice versa, ie: "Gibit[s] (non-network
> binary and single bit)",
> or the "GBytes (network SI and binary multiples of bit)" above.
> If you cross it up or make errors in context in one place that throws all
> your
> docs and configs into question. Even I still mess it up sometimes.
>
> "
> it's easy to forget that "B" means bytes, not bits.
> "
>
> Nope :) Abbr "B" means "byte" (now formally of width eight bits as in
> "octet/o",
> and still unfortunately caveat "bel/B" as in "dB"), and abbr "bit" means
> "bit",
> (and "b" is now just nothing but informal efficient shorthand for
> "bit" if I recall).
>
> https://en.wikipedia.org/wiki/IEC_8-13
> https://en.wikipedia.org/wiki/Byte
> https://en.wikipedia.org/wiki/Octet_(computing)
> https://en.wikipedia.org/wiki/Bit
>
> Anyway, tor relay is network not disk, so I'd suggest megabits,
> or kilo/giga as scale appropriate.
> ___
> 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] Mismatched fingerprints

[usprey]

You can use the "site:" prefix with our friends at google, eg. "site:
https://lists.torproject.org/pipermail/ SEARCHTERM"
On 18 Jan 2015 19:02, "Patrick Scharmer"  wrote:

> Hi,
>
> I’ve been running a bridge for over a year and noticed recently that the
> fingerprint shown in ARM (and that actually works when connecting to the
> bridge) differs from the fingerprint displayed for my bridge on both Atlas
> and Globe. Any thoughts on why this would happen and how to fix it? I’m
> assuming the fingerprint published on Atlas & Globe is the same fingerprint
> that will be distributed by bridges.torproject, is that correct?
>
> Apologies if this is a common question… I’ve only recently joined the
> mailing list and couldn’t find a way to search the archives other than
> browsing.
>
> Regards,
>
> -Pat
>
>
> ___
> 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] Jump in brute force complaints

[usprey]

Regarding SSH I have only received complaints from sysads complaining
about unauthorized connection attempts to port 22 getting caught in
firewalls, sometimes even with no SSH service listening on port 22.
Since I follow the exit guidelines with tor-exit-notice.html on
DirPort, Reverse DNS etc., and the sysads don't even bother to do a
reverse lookup before sending abuse complaints I will not bother
wasting my time on answering them. It is no secret how to properly
secure internet connected systems, and in all cases their firewalls
etc. obviously works, so my message to them, if any, would be "Welcome
to the internet...".

Apart from ssh brutes I have had a few autogenerated complaints from
valuehost.ru.

On 4 January 2015 at 05:27, Kura  wrote:
> I've noticed a rather large jump in abuse emails from admits about brute
> force attempts coming from my exit nodes.
>
> I've had a handful of these in past, as you'd expect but now they are
> arriving multiple times a day, some automated emails, some not.
>
> Has anyone else noticed a jump in abuse complaints?
>
> Curious as to whether it's a spike in the network being used for abuse, more
> admits reading logs or just my luck.
>
> --
> Kura
>
> t: @kuramanga
> w: https://kura.io/
> g: @kura
>
> ___
> 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] HardwareAccel: Current proper use???

[usprey]

> Since the hardware feature became more relevant in the last time i'm really
> looking forward to have a fresh set of eyes looking into it. Sometimes i
> find myself assuming things that shouldn't be assumed when it comes to new
> relays. If you feel the docu lacks something, please provide some input :-)

Will do. =)

On 3 January 2015 at 15:07, Sebastian Urbach  wrote:
> On January 3, 2015 2:42:44 PM usprey  wrote:
>
> Hi,
>
>> On 3 January 2015 at 13:56, Sebastian Urbach  wrote:
>> > On January 3, 2015 10:41:42 AM usprey  wrote:
>> >
>> > Hi usprey,
>> >
>> >> Summary:
>> >> The documentation is still somewhat vague on the best use of the
>> >> "HardwareAccel" option.
>> >>
>> >> > *HardwareAccel* *0*|*1*
>> >
>> >
>> > The docu is not exactly a high-performance howto :-)
>>
>> np, would just like to elaborate this option in the manual for people
>> not fluent in OpenSSL.
>
>
> Since the hardware feature became more relevant in the last time i'm really
> looking forward to have a fresh set of eyes looking into it. Sometimes i
> find myself assuming things that shouldn't be assumed when it comes to new
> relays. If you feel the docu lacks something, please provide some input :-)
>>
>>
>> >
>> >> >
>> >> > If non-zero, try to use built-in (static) crypto hardware
>> >> > acceleration
>> >> > when available. (Default: 0)
>> >> >
>> >> I could not find a definitive answer in the archives or in
>> >>
>> >>
>> >> https://gitweb.torproject.org/tor.git/log/?qt=grep&q=hardwareaccel&showmsg=1
>> >> .
>> >>
>> >> https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration
>> >> claims
>> >> no intervention is needed in regards of aes-ni accelaration, but I
>> >> would
>> >> like to add an explanation or source to this recommendation.
>> >>
>> >> Question_1:
>> >> If my CPU supports and have loaded aesni_intel on linux with OpenSSL is
>> >> 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it?
>> >
>> >
>> > You don't have to change anything with 1.0.1.j-1, leave the default.
>> >
>> >>
>> >> Question_2:
>> >> What does "*built-in (static) crypto hardware acceleration*" refer to?
>> >> Dedicated hardware, CPU-support or...?
>> >
>> >
>> > It specifically means that you have the aes_ni cpu capabilities / flag.
>> > I
>> > have seen this flag on dedicated systems and also on vps systems as
>> > well. If
>> > the cpu / bios provides the flag and all other requirements are met (as
>> > stated in the torservers.net docu) you can use that feature on any
>> > system.
>>
>> k, ty, will venture into OpenSSL docs.
>>
>> >
>> > I would very much appreciate it if you would switch to text mail format,
>> > thanks.
>>
>> k, is that the preferred default on these lists?
>
>
> All lists i know prefer plain text, just better readable for everybody.
>
>
>>
>> >
>> > Thank you very much for running a relay !
>> >
>> >>
>> >> Best regards
>> >>
>> >>
>> >>
>> >> --
>> >> ___
>> >> tor-relays mailing list
>> >> tor-relays@lists.torproject.org
>> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>> >>
>> >
>> >
>> > --
>> > Sincerely yours / Sincères salutations
>> >
>> > Sebastian Urbach
>> >
>> > -
>> > Definition of Tor:
>> > 10% luck, 20% skill, 15% concentrated
>> > power of will, 5% pleasure, 50% pain and
>> > 100% reason to remember the name!
>> > -
>> >
>> >
>> >
>> > ___
>> > 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
>
>
>
> --
> Sincerely yours / Sincères salutations
>
> Sebastian Urbach
>
> -
> Definition of Tor:
> 10% luck, 20% skill, 15% concentrated
> power of will, 5% pleasure, 50% pain and
> 100% reason to remember the name!
> -
>
>
> ___
> 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] Someone broke the tor-relay speed record?

[usprey]

On 3 January 2015 at 12:36, grarpamp  wrote:

> On Sat, Jan 3, 2015 at 3:53 AM, usprey  wrote:
> > I would like to give a worthy mention about price/performance of modern
> AMD
> > CPUs.
> >
> > My current highest observed peak on a $400 AMD (w/o rackcase) machine is
> > 370Mbps running one tor process with two threads.
>
> What cpu model and cpu load percentages at what bandwidth?
>

A8-5600K bought for a cheap private server 1,5 years ago
https://en.wikipedia.org/wiki/List_of_AMD_accelerated_processing_unit_microprocessors#Virgo:_.22Trinity.22_.282012.2C_32_nm.29

I can set up system stats if you want proper figures, but far from full
load with 250Mbps average bidirectional traffic.


> The AMD's seem nice if you don't pay for watts, want ATI opencl
> GPU performance on die, can utilize their cmt setup better
> than htt, or just want a decent cheap cpu (which could indeed be
> interesting to evaluate for lower bandwidth like this 370Mbps).
>

I currently have free hosting for this machine, so power and traffic not an
issue. I expect the kernel to handle the rest. ;)


> AMD's fastest processor seems the fx-9590 4 modules 4.7ghz 220w $230.
> Under full load, my guess is the i7-5820k is about 26% faster for $155
> more, which you'd make back saving watts in 2.25 years.
>

Good point, if your not on a budget and building a private relay. Power
prices also vary a lot between countries and regions.


> I don't know how much Tor benefits from SMT, or how Intel HTT vs
> AMD CMT compares (very few reviews bother to properly test SMT).
>

No idea, should this not be more dependant on the OS?


> ___
> 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] HardwareAccel: Current proper use???

[usprey]

On 3 January 2015 at 13:56, Sebastian Urbach  wrote:
> On January 3, 2015 10:41:42 AM usprey  wrote:
>
> Hi usprey,
>
>> Summary:
>> The documentation is still somewhat vague on the best use of the
>> "HardwareAccel" option.
>>
>> > *HardwareAccel* *0*|*1*
>
>
> The docu is not exactly a high-performance howto :-)

np, would just like to elaborate this option in the manual for people
not fluent in OpenSSL.

>
>> >
>> > If non-zero, try to use built-in (static) crypto hardware acceleration
>> > when available. (Default: 0)
>> >
>> I could not find a definitive answer in the archives or in
>>
>> https://gitweb.torproject.org/tor.git/log/?qt=grep&q=hardwareaccel&showmsg=1
>> .
>>
>> https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration
>> claims
>> no intervention is needed in regards of aes-ni accelaration, but I would
>> like to add an explanation or source to this recommendation.
>>
>> Question_1:
>> If my CPU supports and have loaded aesni_intel on linux with OpenSSL is
>> 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it?
>
>
> You don't have to change anything with 1.0.1.j-1, leave the default.
>
>>
>> Question_2:
>> What does "*built-in (static) crypto hardware acceleration*" refer to?
>> Dedicated hardware, CPU-support or...?
>
>
> It specifically means that you have the aes_ni cpu capabilities / flag. I
> have seen this flag on dedicated systems and also on vps systems as well. If
> the cpu / bios provides the flag and all other requirements are met (as
> stated in the torservers.net docu) you can use that feature on any system.

k, ty, will venture into OpenSSL docs.

>
> I would very much appreciate it if you would switch to text mail format,
> thanks.

k, is that the preferred default on these lists?

>
> Thank you very much for running a relay !
>
>>
>> Best regards
>>
>>
>>
>> --
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
>
> --
> Sincerely yours / Sincères salutations
>
> Sebastian Urbach
>
> -
> Definition of Tor:
> 10% luck, 20% skill, 15% concentrated
> power of will, 5% pleasure, 50% pain and
> 100% reason to remember the name!
> -
>
>
>
> ___
> 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] [tor-talk] HardwareAccel: Current proper use???

[usprey]

On 3 January 2015 at 13:34, coderman  wrote:
> On 1/3/15, usprey  wrote:
>> Summary:
>> The documentation is still somewhat vague on the best use of the
>> "HardwareAccel" option.
>
>
> you could submit a patch ;)
>

I will be glad to, but will have to know what to write first. =)

>
>
>>> *HardwareAccel* *0*|*1*
>>>
>>> If non-zero, try to use built-in (static) crypto hardware acceleration
>>> when available. (Default: 0)
>
> in OpenSSL land, there are two types of crypto offload / hw engines:
>  built-in (static), and dynamically loaded (dynamic).
>
> the "HardwareAccel 1" option says to enable the built-in / static
> engines.  you may have a patched OpenSSL that will automatically try
> dynamic engines without explicitly attempting to load them by name (as
> libengine.so dlopen'ed implementations).
>
>
>
>> https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration
>> claims
>> no intervention is needed in regards of aes-ni accelaration, but I would
>> like to add an explanation or source to this recommendation.
>
> in some versions of OpenSSL, you will need to enable HardwareAccel
> (but not use a dynamic engine - aesni is built-in / static).
>
> you will need to consult the distribution of OpenSSL you are using to
> be sure - it varies by version and pkg maintainers.
>

ty, will research further.

>
>
>> Question_1:
>> If my CPU supports and have loaded aesni_intel on linux with OpenSSL is
>> 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it?
>
> leave HardwareAccel 1, but do not bother with a dynamic named engine opt.

k, ty very much sir! =)

> ___
> 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] HardwareAccel: Current proper use???

[usprey]

Summary:
The documentation is still somewhat vague on the best use of the
"HardwareAccel" option.

> *HardwareAccel* *0*|*1*
>
> If non-zero, try to use built-in (static) crypto hardware acceleration
> when available. (Default: 0)
>
I could not find a definitive answer in the archives or in
https://gitweb.torproject.org/tor.git/log/?qt=grep&q=hardwareaccel&showmsg=1
.

https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration claims
no intervention is needed in regards of aes-ni accelaration, but I would
like to add an explanation or source to this recommendation.

Question_1:
If my CPU supports and have loaded aesni_intel on linux with OpenSSL is
1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it?

Question_2:
What does "*built-in (static) crypto hardware acceleration*" refer to?
Dedicated hardware, CPU-support or...?

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

Re: [tor-relays] Someone broke the tor-relay speed record?

[usprey]

I would like to give a worthy mention about price/performance of modern AMD
CPUs.

My current highest observed peak on a $400 AMD (w/o rackcase) machine is
370Mbps running one tor process with two threads.

On 2 January 2015 at 14:59, grarpamp  wrote:

> Since people aren't going to like paying the 10g switchport
> fee, nor the price of small bandwidth over 1gbps on it,
> the fastest real world box for individual tor nodes is probably
> going to be that i7-5820k off a gig port for $1235 or less.
> ___
> 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] High speed exit question

[usprey]

I am currently peaking 46.39 MBps / 371.12Mbps,
https://atlas.torproject.org/#details/F14B7BF44F9B170DFF628F237E0C7E8D631F957E,
with "NumCPUs 2" on an AMD A8-5600K with 8GB RAM. My setup is based on
https://wiki.archlinux.org/index.php/Tor#.2B100Mbps_Exit_Relay_configuration_example
.

I presume you have read
https://blog.torproject.org/blog/lifecycle-of-a-new-relay, so you know it
will take some time before the network takes full advantage of your new
exit relay.

On 2 January 2015 at 17:03, Austin Bentley  wrote:

> Actually, on 2nd thought, you may not have to limit your bandwidth because
> Tor MAY handle this for you.
>
> Also, it's recommended to run your (presumably, 8) servers on different
> network addresses as well. If you are running a colocation rack this won't
> be difficult, but if you are doing this from your home.. well.. I won't
> start.
>
> On Fri, Jan 2, 2015 at 10:00 AM, Austin Bentley  wrote:
>
>> Yep, you got it. Multiple processes with different configurations. You
>> should also limit their bandwidths proportionally so you don't saturate
>> your network interface.
>>
>> On Fri, Jan 2, 2015 at 9:48 AM, Kura  wrote:
>>
>>> Hey guys, I recently decided to get myself an 8 core, 16 GB RAM machine
>>> to use for running an exit relay and was wondering, Tor only works on one
>>> core, even setting NumCPUs to 2 doesn't do a whole lot so, how is it even
>>> possible to get more than maybe, 300Mbps or so from one relay? Maybe I'm
>>> missing something but, running multiple Tor processes is just going to have
>>> multiple relays with different OR and Dir ports for each, right?
>>>
>>> --
>>> Kura
>>>
>>> t: @kuramanga 
>>> w: https://kura.io/
>>> g: @kura 
>>>
>>> ___
>>> 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

Re: [tor-relays] ntp needs attention

[usprey]

phk to the rescue!

See https://github.com/bsdphk/Ntimed for upcoming ntpd replacement.

On 22 December 2014 at 09:42, Felix  wrote:

> Hi
>
> See: https bugs.debian.org/cgi-bin/bugreport.cgi?bug=773576
>
> Debian will be fixed by 'apt-get update' and 'apt-get upgrade'.
> dpkg.log tells if the fix is in place:
> https security-tracker.debian.org/tracker/CVE-2014-9293 ...
>
> Cheers!
> ___
> 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] Out of memory message

[usprey]

https://gitweb.torproject.org/tor.git/commit/?id=17ecd04fde2fd98b0cca3afb251b7173e22d3f42

On 10 December 2014 at 17:57, Logforme  wrote:

> On 2014-12-10 08:31, Roger Dingledine wrote:
> > Careful with your conclusion there -- because of memory fragmentation,
> > the process can still hold the memory even when Tor has freed the memory.
> htop currently shows 3622/3858 Mem used and 1545/3136 Swap used. (if I
> remember correctly it's usually less than 1000 Mem and 0 Swap used).
> So the attacker (intentional or accidental) actually managed to make Tor
> take all free memory on the machine before the MaxMemInQueues function
> stepped in. And now I have no way to release that memory short of
> restarting tor. If I used the machine for something apart from tor it
> would have been a successful attack.
> Guess I need to set the MaxMemInQueues parameter to something other than
> 0, maybe 2GB? What's the "reasonable default" for MaxMemInQueues? Some
> percentage of total RAM?
> ___
> 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] specifying your own entrance and exit nodes

[usprey]

Inline below.

On 11 December 2014 at 01:46, tor-exit0  wrote:

> On 12/10/2014 4:52 PM, usprey wrote:
>
> > I do not have a full understanding of how the DirAuth works, but how
> > about an out of band verification process, to ensure the
> > trustworthiness, for exit nodes specifically. This would minimize the
> > hazzle for people who wishes to use trusted exit nodes, and maximize the
> > number of explicitly trusted exit nodes.
>
> How would the trust be quantified by such a verification process?


You could use existing web of trust systems to let maintainers sign the
relays fingerprint.
In addition to this users could also sign the fingerprint and the exit
would first be flagged trusted when a critical mass of users have signed.
I'm aware this breaks anonymity, but would be a way to flag an exit as
trusted.


> For
> example, how would this prevent the operator of a good exit from
> changing their mind about tampering with traffic or the cooperation of
> one or more exit owners in monitoring or sharing traffic information for
> correlation?


It won't, but the maintainer would be putting her name and reputation on
the line, in the web of trust fingerprint scenario above. Code words for
trust is openness and accountability.
I'm not aware how one acquires a bad exit flag, but it should be possible
to automate tests verifying non-interference with exit connections.


> I'd also be curious how such a system would stand up in the
> event that control over a validated exit is compromised without the
> owner realizing it.


I suspect that most people contributing +100Mbps bandwidth, are in some way
IT professionals and know what they are doing and have followed the general
guidelines for physical, network and software security.
A signing process for a maintainer could also include a statement of
compliance with specific guidelines.


> It seems to me that most validation techniques offer
> a trade off between accountability and anonymity which may also pose a
> concern for some people.
>

Definitely, why it shouldn't be mandatory, but a way to flag trusted and
accountable exits.


>
>
>
> ___
> 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] specifying your own entrance and exit nodes

[usprey]

I run an exit node,
https://atlas.torproject.org/#details/F14B7BF44F9B170DFF628F237E0C7E8D631F957E,
and I'm also quite new on the list and learn new things about Tor everyday,
so please bear with me.

I do not have a full understanding of how the DirAuth works, but how about
an out of band verification process, to ensure the trustworthiness, for
exit nodes specifically. This would minimize the hazzle for people who
wishes to use trusted exit nodes, and maximize the number of explicitly
trusted exit nodes. Since relay maintainers are already publicly listed and
traceable I would not have any problem signing off on my own, and a few
other maintainers I know personally, exit nodes.

As per
https://compass.torproject.org/#?exit_filter=all_relays&links&sort=cw&sort_reverse&country=&exits_only&top=10
the
exit probability of the Top 10 exit relays with the highest consensus
weight is 12,2046%, and per
https://compass.torproject.org/#?exit_filter=fast_exits_only&links&sort=cw&sort_reverse&country=&exits_only&top=10
the
exit probability of the Top 10 fast exit relays is 11,2452%, so you
wouldn't need many maintainers joining a signing/verification scheme to
account for a lot of the bandwidth on the network.

On 10 December 2014 at 21:58, Seth  wrote:

> Assuming there are certain Tor notes being run by parties hostile to my
> own interests, what are
> the pros and cons of specifying one's own list of trusted entrance and
> exit nodes?
>
> I run a Tor relay at home 24/7 and use that as my entrance point. I do
> this to provide cover traffic for my own Tor use as well as help out the
> network.
>
> I also try to use Tor for all my daily web browsing when possible. This
> has given be a lot of headaches.
>
> Besides the demoralizing barrage of Cloudfare captchas, I've had a lot of
> problems with dropped connections, timeouts, SSL cert warnings, fatal
> errors connecting to HTTPS sites. I started to get a gut feeling, warranted
> or not, that some exits nodes might be meddling with my traffic.
>
> To combat this I changed the configuration on my local Tor relay to use
> only exit nodes run by organizations or people that I felt I could trust. I
> didn't bother with specifying entrance nodes because I could not see what
> the gain would be.
>
> This seems to have curbed some of the problems, with the tradeoff that
> responsiveness is much more inconsistent.
>
> I'm just curious if restricting exit nodes to a few dozen that you trust
> effectively defeats most of the purpose of using Tor. What would be the
> bare minimum of Tor exit nodes a person would need to use in order to make
> life difficult for the Panopticon surveillor scum?
>
> If this post is more appropriate for Tor-talk, please let me know
> ___
> 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] Atlas slow/not working?

[usprey]

My hats off to you good Sirs!!! Have been missing my atlas and globe fix so
very much. =)

https://compass.torproject.org/ seems to wokr although i can't tell if it
is with old data.

On 6 December 2014 at 17:34,  wrote:

> Hey all,
>
> Yes the mirrors https://atlas.thecthulhu.com and
> https://globe.thecthulhu.com are both working but Compass is not yet
> configured (we'll get around to that soon, we're having some issues behind
> the scenes right now). The mirrors are permanent and on a high spec server
> so if there are ever issues with the primary services you can always
> rollover to those (or alternatively use those as the primary ones to take
> the bandwidth load off the Tor Project servers). Onionoo is also on the
> servers which is a copy of the official server (it hasn't been initialised
> from scratch yet) which is why it works even when the primary service is
> down (I've had a few emails asking how I made them work when the primary
> server is down, so hope that clears it up for you).
>
> Both myself and Karsten have access to the above mirrors so if they
> develop problems then either of us are available to look into it.
>
> Regards,
> -T
>
> On 2014-12-06 16:24, Abhiram Chintangal wrote:
>
>> Thanks! I got it to work now.
>>
>> On Sat, Dec 6, 2014 at 11:14 AM, Justaguy  wrote:
>>
>>   https://trac.torproject.org/projects/tor/ticket/13905
>>>
>>> This can be solved by using mirrors like https://atlas.thecthulhu.com/
>>>
>>> --
>>> Contact:
>>> Irc, justaguy @ Freenode or OFTC
>>>
>>> OTR fingerprint: FF6D1AC2 13F38B15 EDB21522 D3530A6F 6EE01996
>>>
>>>
>>>
>>> On 12/06/2014 05:12 PM, Abhiram Chintangal wrote:
>>>
>>>  Hello,
>>>
>>> I am not able to check my relays status via Atlas for the last two days.
>>> Any ideas?
>>>
>>>  Thanks
>>>  --
>>>  Abhiram Chintangal
>>>
>>> I guess we agree with reason, but now it's a matter of disposition.
>>>
>>>
>>> ___
>>> tor-relays mailing listtor-relays@lists.torproject.orghttps://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
>>
> ___
> 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] ArchWiki article about fast relay configuration

[usprey]

Hi List

I have written my own notes into
https://wiki.archlinux.org/index.php/Tor#.2B100Mbps_Exit_Relay_configuration_example
.

All and any feedback will be appreciated!

Are there any privacy concerns about using pdnsd to cache DNS locally?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] doc/HARDENING Draft

[usprey]

cron-apt is also a viable option for debians.

https://wiki.archlinux.org/ is afaik the best standard repository of all
knowledge and wisdom about current linux, always solved my debian-*codename*
 problems.

On 25 November 2014 at 05:29, Tor Operator  wrote:

> On Mon, Nov 24, 2014 at 06:09:34PM -0500, Libertas wrote:
> > Be sure to stay up-to-date using apt-get, and consider using cron-apt to
> > automatically update:
> > https://www.debian.org/doc/manuals/debian-faq/ch-uptodate.en.html
>
> Maybe it also worth covering unattended-upgrades package to keep Debian up
> to
> date. It requires to run "dpkg-reconfigure unattended-upgrades" after
> install
> as it doesn't enable automatic upgrades right away after install and
> supposedly
> don't do potentially dangerous operations like kernel upgrades
> automatically.
> Using it in production myself, really helps to keep OS up to date.
>
> Also for protecting SSH SSHGuard is in my opinion a much better choice as
> it
> supports IPv6 unlike fail2ban (I heard there were patches for fail2ban to
> address that but I'm not sure if they are already in mainstream and
> available
> in all distributions).
>
> --
> Random
>
> ___
> 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] Fast Exit Node Operators - ISP in US

[usprey]

http://blog.censurfridns.dk/en

Pretty sure this is no fon.

On 24 November 2014 at 02:18, Seth  wrote:

> On Sun, 23 Nov 2014 16:53:03 -0800, ZEROF  wrote:
>
>  I'm not using opendns. OpenNic and OpenDNS are not same thing.
>>
>
> I'm aware of the distinction.
>
> What I was trying to point out for the benefit of people just getting
> started with dnscrypt-proxy, is that by default it uses OpenDNS servers.
>
> At least it has in every environment that I've set it up in so far.
>
> ___
> 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