[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Tor bug?: AllowInvalidNodes

This is all very worrying.

First I find out that my torcc config file which is configured to "AllowUnverifiedNodes middle,rendezvous" is a no longer valid config statement.

Then I find out that the replacement "AllowInvalidNodes middle,rendezvous" doesnt work.

Now I find out that it was never intended to work and that it was never an  "AllowUnverifiedNodes" replacement.

Q. Were we Alerted to such an important change?

If some "unverifiednode" exit server adversary has set themselves up in business of monitoring TOR users then isnt it because  "AllowUnverifiedNodes" was removed (effectively).

I agree, the latest change will make little to secure Tor exit servers now from this adversary, they'll just change their IP addresses to get around it. Surely they will be watching this forum. 

Perhaps the best thing would be to re-instate  "AllowUnverifiedNodes" immediately and force this adversary to register their nodes. 

Even if they forge their identities for the sake of the registration at least, in future, we would have forewarning which would make it easier to monitor and alert Tor users to potential (I assume this is a countries security service) mass logging at Tor exit nodes.

Once again I repeat this is ALL very worrying.

Is there a co-incidence with the removal of  "AllowUnverifiedNodes" and the appearance of these adversary servers?

I must say this couldnt have worked out any worse even if the devs had been working for the adversary.

Personally, I think its irrelevant today, that at one time persons had to be known personally to run a verified server. Quaint but irrelevant. But hey, I dont mind having someone round to my place from the UK to verify me. Why not have 3 levels of security - level 2 - Registered - just what we have now. Level 1 - Verified - visit their setup. Level 3 - unregistered & unverified. And give us a config statement to use these levels or not.

On a related issue, I have attempted to the "ExcludeNodes" config and it doesnt seem to work. I am sure that of the dozens of nodes I've tried to exclude (and failed to exclude - test only) ALL of them cannot be my "guard" nodes. Ok this might only be winOS, perhaps everyone should check it out for themselves. Just to be sure. I've noticed others have seen similar. Re-check.

This adds to the worry.

You cant exclude nodes, you cant insist on verification. What can you do that works ?


----- Original Message ----- 
From: "Roger Dingledine" <arma@xxxxxxx>
To: <or-talk@xxxxxxxxxxxxx>
Sent: Wednesday, August 16, 2006 6:42 PM
Subject: Re: Tor bug?: AllowInvalidNodes

> On Wed, Aug 16, 2006 at 07:28:25PM +0200, Gompie wrote:
> > Sorry, but I think that patch is not the correct way to go. With 
> > "AllowInvalidNodes middle,rendezvous" (Tor v. in my 
> > torrc-file, I expect my Tor client not to build a circuit that uses an 
> > invalid exit node. So apparently, something concerning this option is 
> > broken and this should be fixed.
> The fundamental confusion here is that the word 'invalid' means many
> things to many people, but it means pretty much nothing to Tor. The
> exit.pl script that Geoff wrote and runs on Serifos uses the phrase "not
> a valid Tor server" to mean "not a Tor server as far as I know". The
> word "valid" with respect to the AllowInvalidNodes config option is
> simply defined as "not manually designed by the directory authorities
> as invalid".
> The reason why serifos's exit.pl script is confused as to whether these
> particular IP addresses are Tor servers is because they publishes one
> IP but their traffic comes out another one. This is common practice for
> multi-homed servers, and there are other networking features that make
> it plausible too.
> We have no master way of deciding whether a server is safe or not. Once
> upon a time, we demanded that I had met each server operator personally.
> That turned out to scale even less well than I had expected it to. So
> the answer now is to aim to grow the Tor network large enough that few
> adversaries are big enough to be able to attack it "well". There are also
> some research avenues that seem promising but have a lot of hurdles yet
> to overcome (e.g. http://freehaven.net/anonbib/#feamster:wpes2004).
> That said, I suggest you forget all about the AllowInvalidNodes config
> option. It's not in the sample torrc that we ship. It barely exists
> anymore.
> Hope that helps,
> --Roger

Message sent with Supanet E-mail

Signup to supanet at https://signup.supanet.com/cgi-bin/signup?_origin=sigwebmail