Hi,
my relays are getting 500 error while fetching data from authority dizum.
Can someone explain what is happening with this tor authority?
Regards,
Klaus
14:25:51 [WARN] Received http status code 500 ("Internal Server Error") from
server '194.109.206.212:80' while fetching
"/tor/server/d/C
On Jan 9, 2012, at 5:35 PM, Klaus Layer wrote:
> Hi,
>
> my relays are getting 500 error while fetching data from authority dizum.
>
> Can someone explain what is happening with this tor authority?
>
> Regards,
>
> Klaus
>
> 14:25:51 [WARN] Received http status code 500 ("Internal Server Err
On Jan 9, 2012, at 5:49 PM, Sebastian Hahn wrote:
> On Jan 9, 2012, at 5:35 PM, Klaus Layer wrote:
>> Hi,
>>
>> my relays are getting 500 error while fetching data from authority dizum.
>>
>> Can someone explain what is happening with this tor authority?
>>
>> Regards,
>>
>> Klaus
>>
>> 14:25
Sebastian Hahn wrote on 09.01.2012:
> Looks like dizum is fixed. Some overzealous firewall issue. Thanks for
> reporting it here!
Thanks for your quick reply.
Klaus
signature.asc
Description: This is a digitally signed message part.
___
tor-relays mai
Shouldn't this be treated more seriously? There are literally over 100
high bandwidth relays, which should specify a family but which don't.
If you monitor a client, it is very frequently that circuits are built
where two relays are clearly controlled by the same person.
As a first try I mailed to
> Shouldn't this be treated more seriously?
How? The Tor admins have to *request* this behavior of relay operators because
there's no way to enforce such a rule.
On Monday, January 9, 2012 5:13pm, "Aurel W." said:
> Shouldn't this be treated more seriously? There are literally over 100
> hig
On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. wrote:
> Shouldn't this be treated more seriously? There are literally over 100
> high bandwidth relays, which should specify a family but which don't.
> If you monitor a client, it is very frequently that circuits are built
> where two relays are clearly c
Maybe this is why my client is taking so long to load
at the moment. At first I thought it was my update to
ossl 100f, but after checking 100e again, it's not. Tor
currently sits in the netstatus consensus and missing
dir auth phases for indefinite tens of minutes before
coming online.
valid-until
> Malicious relays trying to de-anonimize people are not going to use
> MyFamily for obvious reasons, and also they will not choose an obvious
> nick sequence like MetallicaFan1, MetallicaFan2,etc
> So it seems to me this option has only theoretical benefit, but in
> practice it's naive.
True, but
Wouldn't it be possible to code the Tor clients to not build circuits
using relays in the same /24 or with "similar" names? While that wouldn't
fix ALL possible attack scenarios, that could certainly help, and help
against accidental (or malicious) misconfigured nodes.
On Tue, 10 Jan 2012 00:28:16
> Wouldn't it be possible to code the Tor clients to not build circuits
> using relays in the same /24 or with "similar" names?
Tor already avoids using multiple relays in a given /16 subnet.
https://gitweb.torproject.org/torspec.git/blob/HEAD:/path-spec.txt#l184
__
Hi,
freedompenguin v3 orport=9001 AC0AF18E61A3660B1F3BAC9FF9DF061D9E446735
May someone add the data to the add_default_trusted_dirservers()
function in config.c, using the syntax "v3ident=".
Thanks.
Btw. i respond pretty fast to server / network issues ;-)
--
Mit freundlichen Grüßen / Yours s
12 matches
Mail list logo
