Re: [tor-relays] torworld relays in entry and exit position

[nusenu]

Security TorWorld wrote (2016-11-14):
> We believe that next month on the 1st of December would be a good time
> to add this feature.

What is the current state on this?

You are still on the top of this list:
https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt



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

Re: [tor-relays] 0.2.8.11 bridge + hidden service, restart loop

[Ivan Markin]

Probably this?

> **Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Directory
> /var/lib/tor/hidden_service/ cannot be read: Permission denied**
> **Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Failed to
> parse/validate config: Failed to configure rendezvous 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

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Ivan Markin]

dawuud:
>>> Maybe you could also implement my Tor guard discovery
>>> attack that uses this vulnerability?
>>
>> Why not. I just don't know what the attack is. Can you point me to it?
> 
> On second thought I guess we better stick to writing scanners because if we
> start writing exploits then eventually some script kitty will come along and
> try to attack the Tor network with it; and even though my attack might not 
> work
> it involves doing various things that utilize resources on the Tor network;
> so it would be bad for the health of the Tor network.

Right, I didn't mean that to be an exploit but just a PoC of this attack
vector. But you're right, I haven't thought that it will put load on the
network, and doing this is definitely not OK. It's not just some
harmless TCP segments, there is much more than this (circuit rebuilding,
etc).

> It's traffic profile would be obviously identifiable for passive network 
> observers.
> A nation state actor would have much better/faster results using other
> well known publicly documented Tor guard discovery attacks.
> Pretty sure they like to be sneaky when they deanonymize Tor circuits.

I doesn't mean that nobody would like to use it. There are attackers
that use botnets to do their nasty business and they don't care much
about how visible it is.

> I would however be very interested to hear back from tor-relay operators
> 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
even faster), it may indicate that there is some aggressive scanning is
going on by multiple parties.

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

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[dawuud]

> > btw i'm surprised you wrote 
> > https://github.com/nogoegst/rough/blob/master/tcp.go
> > instead of using https://github.com/google/gopacket
> 
> You shouldn't; rough is just a convenient wrapper on top of TCP-ish
> stuff from gopacket (it makes TCP hacks simpler).

ah right. cool.

> > Maybe you could also implement my Tor guard discovery
> > attack that uses this vulnerability?
> 
> Why not. I just don't know what the attack is. Can you point me to it?

On second thought I guess we better stick to writing scanners because if we
start writing exploits then eventually some script kitty will come along and
try to attack the Tor network with it; and even though my attack might not work
it involves doing various things that utilize resources on the Tor network;
so it would be bad for the health of the Tor network.

> > I've been asked to write a proof of concept but I don't feel motivated to 
> > do so.
> > Also, there are some doubts about weather this guard discovery attack would 
> > be
> > feasible on the real Tor network... though we could probably make it work 
> > in a test network.
> > 
> > Now that such a small percentage of the Tor network is vulnerable it's 
> > probably safe/responsible
> > for me to post my theoretic Tor guard discovery attack, right?
> 
> Hmm, I *don't* think that 1/4 of the network is actually small
> percentage... [I think we should somehow encourage vulnerable relays to
> update their kernels to lower affected percentage below ~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.

It's traffic profile would be obviously identifiable for passive network 
observers.
A nation state actor would have much better/faster results using other
well known publicly documented Tor guard discovery attacks.
Pretty sure they like to be sneaky when they deanonymize Tor circuits.

I would however be very interested to hear back from tor-relay operators
if any of them have found Challenge ACK counter values higher than
a million... which would indicate some kind of funny business.


Cheers,
David


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] 0.2.8.11 bridge + hidden service, restart loop

[Petrusko]

Hey,

Compiled current 0.2.8.11 (git-c49e563d0096aa5d) on a RPi,
set up as a bridge + hidden service (http)

Before update, everything was fine.
Now, it's starting only fine when only bridge is enabled

If hidden service is enabled in torrc, some problems :
- restart loop
- /var/log/tor/notices.log is not used. but can watch log in
/var/log/syslog file...

Custom hostname + private_key in hidden_service, it was nice before...

Thx for your help :)


Dec  9 23:48:06 XXX systemd[1]: Starting Anonymizing overlay network for
TCP...
Dec  9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.336 [notice] Tor
v0.2.8.11 (git-c49e563d0096aa5d) running on Linux with Libevent
2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Dec  9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.342 [notice] Tor can't
help you if you use it wrong! Learn how to be safe at
https://www.torproject.org/download/download#warning
Dec  9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.343 [notice] Read
configuration file "/usr/share/tor/tor-service-defaults-torrc".
Dec  9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.343 [notice] Read
configuration file "/etc/tor/torrc".
Dec  9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.399 [warn] Tor is
currently configured as a relay and a hidden service. That's not very
secure: you should probably run your hidden service in a separate Tor
process, at least -- see https://trac.torproject.org/8742
Dec  9 23:48:08 XXX tor[3935]: Dec 09 23:48:08.405 [notice] Based on
detected system memory, MaxMemInQueues is set to 361 MB. You can
override this by setting MaxMemInQueues by hand.
Dec  9 23:48:08 XXX tor[3935]: Configuration was valid
Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.088 [notice] Tor
v0.2.8.11 (git-c49e563d0096aa5d) running on Linux with Libevent
2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.093 [notice] Tor can't
help you if you use it wrong! Learn how to be safe at
https://www.torproject.org/download/download#warning
Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.093 [notice] Read
configuration file "/usr/share/tor/tor-service-defaults-torrc".
Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.094 [notice] Read
configuration file "/etc/tor/torrc".
Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.151 [warn] Tor is
currently configured as a relay and a hidden service. That's not very
secure: you should probably run your hidden service in a separate Tor
process, at least -- see https://trac.torproject.org/8742
Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.157 [notice] Based on
detected system memory, MaxMemInQueues is set to 361 MB. You can
override this by setting MaxMemInQueues by hand.
*Dec  9 23:48:10 XXX systemd[1]: tor@default.service: main process
exited, code=exited, status=1/FAILURE**
**Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Directory
/var/lib/tor/hidden_service/ cannot be read: Permission denied**
**Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [warn] Failed to
parse/validate config: Failed to configure rendezvous options. See logs
for details.**
**Dec  9 23:48:10 XXX tor[3941]: Dec 09 23:48:10.165 [err] Reading
config failed--see warnings above.**
**Dec  9 23:48:10 XXX systemd[1]: Failed to start Anonymizing overlay
network for TCP.**
**Dec  9 23:48:10 XXX systemd[1]: Unit tor@default.service entered
failed state.**
**Dec  9 23:48:10 XXX systemd[1]: tor@default.service holdoff time over,
scheduling restart.*
Dec  9 23:48:10 XXX systemd[1]: Stopping Anonymizing overlay network for
TCP...
Dec  9 23:48:10 XXX systemd[1]: Starting Anonymizing overlay network for
TCP...

-- 
Petrusko
EBE23AE5



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

Re: [tor-relays] Exit Node Geographical Location

[Sec INT]

Good work Chris - not sure if you know yet but what sort of price per month and 
is it vps or dedicated? 

Cheers
Mark B


> On 9 Dec 2016, at 14:17, Michael Armbruster  wrote:
> 
>> On 2016-12-09 at 15:09, Chris Adams wrote:
>> Okay,
>> 
>> So I've found a ISP in Kenya that says they're happy to host a tor exit
>> node. The ping is 270ms from a Canadian ISP, 16 hops. 183ms from
>> Germany, 13 hops.
>> 
>> Ultimately, am I making the tor network better or worse, if I were to
>> set up some tor nodes here?
>> 
>> - Chris
> 
> Hi Chris,
> 
> If it is affordable, it sounds like a great addition. 183ms ping from
> Germany isn't that bad at all. Sometimes I have pings to Canada or USA
> at 200ms, depending on the exact route.
> 
> If they are happy to host a Tor exit node, you could add them to the ISP
> list in the wiki (though the spam filter has problems right now), or at
> least mention them here if you want to :)
> 
> Best,
> Michael
> 
> 
> 
> ___
> 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] Exit Node Geographical Location

[Michael Armbruster]

On 2016-12-09 at 15:09, Chris Adams wrote:
> Okay,
> 
> So I've found a ISP in Kenya that says they're happy to host a tor exit
> node. The ping is 270ms from a Canadian ISP, 16 hops. 183ms from
> Germany, 13 hops.
> 
> Ultimately, am I making the tor network better or worse, if I were to
> set up some tor nodes here?
> 
> - Chris

Hi Chris,

If it is affordable, it sounds like a great addition. 183ms ping from
Germany isn't that bad at all. Sometimes I have pings to Canada or USA
at 200ms, depending on the exact route.

If they are happy to host a Tor exit node, you could add them to the ISP
list in the wiki (though the spam filter has problems right now), or at
least mention them here if you want to :)

Best,
Michael





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

Re: [tor-relays] Exit Node Geographical Location

[Chris Adams]

Okay,

So I've found a ISP in Kenya that says they're happy to host a tor exit
node. The ping is 270ms from a Canadian ISP, 16 hops. 183ms from Germany,
13 hops.

Ultimately, am I making the tor network better or worse, if I were to set
up some tor nodes here?

- Chris

On Fri, Dec 9, 2016 at 8:41 AM, Sebastian Hahn 
wrote:

>
> > On 09 Dec 2016, at 09:34, teor  wrote:
> >
> >
> >> On 8 Dec. 2016, at 22:08, Sec INT  wrote:
> >>
> >> US just has alot of people trying to exit there - so its always busy
> >
> > Tor clients choose exits at random, based on the ports the exit allows.
> > They *do not* try to find an exit close to the site they are going to.
> >
> >> - I find Tor follows the money mostly - high concentration in W.Europe
> and US but drops sharply anywhere else -
> >
> > All the tor bandwidth-measuring authorities are also located in either
> > Western Europe or the US. Relays closer to a bandwidth authority
> > (lower network latency) are measured faster than those further away.
> >
> > This is a side-effect of measuring the delay in transmission inside
> > the relay itself.
> >
> >> On 9 Dec. 2016, at 06:23, Duncan Guthrie  wrote:
> >>
> >> Thus, running relays in Africa and Asia should be a priority right now.
> >
> > To make this work well, we would need bandwidth authorities in Africa
> > and Asia. Otherwise, those relays won't be used much.
> >
> > (We're working on it - I hope!)
>
> Just adding bw auths in Africa won't do too much, because the relevant
> factor is who is dominating the median. If we had a majority of bwauths
> there, the european/us relays would get measured worse. Also, the more
> diversity we have, the worse the latency gets anyway - this is not to
> say that we shouldn't add more diversity, but there'll be clearly
> noticable issues.
>
> Maybe we could add something to the current system where we try to
> estimate how much path length will make a measurement worse by default,
> and compensate for that somehow. Otoh, the current state of bwauths is
> so sad that I don't know if that'd be even remotely possible. Also such
> a system must be resistant to tampering, of course.
>
> Cheers
> Sebastian
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>



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

[tor-relays] Belarus (finally) bans Tor

[Rana]

https://ooni.torproject.org/post/belarus-fries-onion/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[grarpamp]

On Fri, Dec 9, 2016 at 4:53 AM, Roman Mamedov  wrote:
> option available today, and you don't have to go back to Pentium 200 to avoid

Using such a relic as a scrub firewall might protect you from magic packets
launched by your adversaries towards one of those listening transistors
in your shiny new Skylake you'd otherwise have directly connected
to the net.

> It's not like they are auto-downloaded from
> the Internet directly by your CPU

Billions of transistors, billions of packets, billions of bits, billions
of broadcast internet 'scans', who's watching...

> Sure there still can be subtle bugs and backdoors, but those will need to be
> subtle, well hidden, likely more difficult to exploit, and likely having much
> less of a "feature set" when exploited. Not to mention the devastating
> reputation effect on the vendor if uncovered.

There may not be any evil silicon code, perhaps just an agnostic monitor
vm, external pushed codeload then exec trigger, they'll call it an undoc
engineering feature, AMT precursor, not meant for public use, tie it to
some other legit thing, whatever, no problem.

>> #OpenFabs printing #OpenDesigns
> As far as I know there's no fully free and open chip right now which provides

That's because no one's giving any significant their
free time / money / research to figure out how to do it,
let alone develop talk about it as a serious global concept
and goal and get it done. Always 'fab and open too costly'
end convo. Bullshit, not costly per interested capita.

What saying is in environment of secret HW no point in betting
hardware trust right now... for tor relays or anything else.
Lot of HW is proving to be so buggy, if not evil, that it's exploited
and exec'd to become evil.
So buy whatever's interesting, put opensource OS on it and
pray neither of them are fucked.
And hedge your future bet by figuring out #OpenFabs
hardware just like you figured out OpenSource software.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] All I want for Chrismas is a bloody t-shirt

[Matthias Fetzer]

On 2016-12-09 11:04, teor wrote:
On 9 Dec. 2016, at 20:45, Dakota Hourie  
wrote:


Also been looking for a T-shirt. I would even be willing to buy it! 
How

do I contact Jon?
-
Dakota Hourie
Outfall Exits Operator


I have CC'd Jon, go easy on him, it's a busy month!

You can't buy a t-shirt, but they are available by donation:
https://donate.torproject.org/



Back when I messaged him, I did not receive any reply at all.
Does he actually send out shirts?

If I got that right, I should be eligible to receive one,
for running my relays: https://atlas.torproject.org/#search/rofltor

Cheers,

Matthias


T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
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] All I want for Chrismas is a bloody t-shirt

[teor]

> On 9 Dec. 2016, at 20:45, Dakota Hourie  wrote:
> 
> Also been looking for a T-shirt. I would even be willing to buy it! How
> do I contact Jon?
> -
> Dakota Hourie
> Outfall Exits Operator

I have CC'd Jon, go easy on him, it's a busy month!

You can't buy a t-shirt, but they are available by donation:
https://donate.torproject.org/

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




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

Re: [tor-relays] Exploiting firmware

[Roman Mamedov]

On Fri, 9 Dec 2016 04:17:49 -0500
grarpamp  wrote:

> >> Intel ME/AMT concerns me too
> 
> > AMD Family 15h itself is safe.
> 
> No one has any proof of that for any modern cpu from any
> maker, featureset irrelavant.

Sure, to clarify what's meant here is "it does not implement the actual
backdoor-like feature (separate CPU-within-CPU running proprietary code and
having super-user rights over the rest of the system and full access to
everything) in the form of 'Platform Security Processor' or 'Intel Management
Engine'". Point is if you wanted a desktop CPU without such feature, there's an
option available today, and you don't have to go back to Pentium 200 to avoid
it.

> They all accept microcode updates, which btw are all encrypted closed binary
> blobs.

Those are applied by your BIOS or your OS.
https://packages.debian.org/jessie/amd64-microcode
https://packages.debian.org/jessie/intel-microcode
You don't HAVE to install those. It's not like they are auto-downloaded from
the Internet directly by your CPU (at least if your CPU doesn't have those
AMT/PSP things :).

> And the chips themselves are fully closed source containing billions
> of transistors. You simply have no idea what's in there and no way to
> economically and publicly test or negotiate to find out and openly publish
> it all.

Sure there still can be subtle bugs and backdoors, but those will need to be
subtle, well hidden, likely more difficult to exploit, and likely having much
less of a "feature set" when exploited. Not to mention the devastating
reputation effect on the vendor if uncovered.

> Billions of secret transistors... billions.
> Not good, and not necessary.
> 
> #OpenFabs printing #OpenDesigns

As far as I know there's no fully free and open chip right now which provides
performance expected of a modern desktop or server. There is the TALOS
project[1], but for most people it'll be a non-starter due to price. And even
there from what I see you don't get it made on an open fab. So we need to
choose the least evil option from what we have available, and to me the AMD FX
appears to be a win in that regard.

[1]
https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] All I want for Chrismas is a bloody t-shirt

[Dakota Hourie]

Also been looking for a T-shirt. I would even be willing to buy it! How
do I contact Jon?
-
Dakota Hourie
Outfall Exits Operator

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

Re: [tor-relays] Exploiting firmware

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
grarpamp
Sent: Friday, December 09, 2016 11:18 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Exploiting firmware

>>> Intel ME/AMT concerns me too

>> AMD Family 15h itself is safe.

>No one has any proof of that for any modern cpu from any maker, featureset 
>irrelavant. They all accept microcode updates, which btw are all encrypted 
>closed binary blobs. And the chips themselves are fully closed >source 
>containing billions of transistors. You simply have no idea what's in there 
>and no way to economically and publicly test or negotiate to find out and 
>openly publish it all.

>Talking about known shit like advertised ME/AMT + LM-NIC's corp management 
>platform is fine, you might be able to mitigate.
>But it's the unknown that will kill you.

>Billions of secret transistors... billions.
>Not good, and not necessary.

Agreed. Effort spent on guessing which closed source processor is safe is a 
wasted effort, and any conclusion that a certain processor is "safe" is a 
dangerous delusion resulting in flawed threat models. Just modify your threat 
model with the compromised processor assumption, calculate the risk of your 
specific computer being targeted, mitigate to the extent possible and get on 
with your life.

Rana

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

Re: [tor-relays] Exploiting firmware

[grarpamp]

>> Intel ME/AMT concerns me too

> AMD Family 15h itself is safe.

No one has any proof of that for any modern cpu from any
maker, featureset irrelavant. They all accept microcode updates,
which btw are all encrypted closed binary blobs. And the
chips themselves are fully closed source containing billions
of transistors. You simply have no idea what's in there
and no way to economically and publicly test or negotiate
to find out and openly publish it all.

Talking about known shit like advertised ME/AMT + LM-NIC's
corp management platform is fine, you might be able to mitigate.
But it's the unknown that will kill you.

Billions of secret transistors... billions.
Not good, and not necessary.

#OpenFabs printing #OpenDesigns
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit Node Geographical Location

[Sebastian Hahn]

> On 09 Dec 2016, at 09:34, teor  wrote:
> 
> 
>> On 8 Dec. 2016, at 22:08, Sec INT  wrote:
>> 
>> US just has alot of people trying to exit there - so its always busy
> 
> Tor clients choose exits at random, based on the ports the exit allows.
> They *do not* try to find an exit close to the site they are going to.
> 
>> - I find Tor follows the money mostly - high concentration in W.Europe and 
>> US but drops sharply anywhere else - 
> 
> All the tor bandwidth-measuring authorities are also located in either
> Western Europe or the US. Relays closer to a bandwidth authority
> (lower network latency) are measured faster than those further away.
> 
> This is a side-effect of measuring the delay in transmission inside
> the relay itself.
> 
>> On 9 Dec. 2016, at 06:23, Duncan Guthrie  wrote:
>> 
>> Thus, running relays in Africa and Asia should be a priority right now.
> 
> To make this work well, we would need bandwidth authorities in Africa
> and Asia. Otherwise, those relays won't be used much.
> 
> (We're working on it - I hope!)

Just adding bw auths in Africa won't do too much, because the relevant
factor is who is dominating the median. If we had a majority of bwauths
there, the european/us relays would get measured worse. Also, the more
diversity we have, the worse the latency gets anyway - this is not to
say that we shouldn't add more diversity, but there'll be clearly
noticable issues.

Maybe we could add something to the current system where we try to
estimate how much path length will make a measurement worse by default,
and compensate for that somehow. Otoh, the current state of bwauths is
so sad that I don't know if that'd be even remotely possible. Also such
a system must be resistant to tampering, of course.

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

Re: [tor-relays] Exit Node Geographical Location

[teor]

> On 8 Dec. 2016, at 22:08, Sec INT  wrote:
> 
> US just has alot of people trying to exit there - so its always busy

Tor clients choose exits at random, based on the ports the exit allows.
They *do not* try to find an exit close to the site they are going to.

> - I find Tor follows the money mostly - high concentration in W.Europe and US 
> but drops sharply anywhere else - 

All the tor bandwidth-measuring authorities are also located in either
Western Europe or the US. Relays closer to a bandwidth authority
(lower network latency) are measured faster than those further away.

This is a side-effect of measuring the delay in transmission inside
the relay itself.

> On 9 Dec. 2016, at 06:23, Duncan Guthrie  wrote:
> 
> Thus, running relays in Africa and Asia should be a priority right now.

To make this work well, we would need bandwidth authorities in Africa
and Asia. Otherwise, those relays won't be used much.

(We're working on it - I hope!)

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




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