[tor-relays] tor-relays Digest, Vol 12, Issue 9

Jeffrey Ye jeffrey.ye at live.com
Tue Jan 10 12:40:48 UTC 2012




> From: tor-relays-request at lists.torproject.org
> Subject: tor-relays Digest, Vol 12, Issue 9
> To: tor-relays at lists.torproject.org
> Date: Tue, 10 Jan 2012 12:00:02 +0000
> 
> Send tor-relays mailing list submissions to
> 	tor-relays at lists.torproject.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> or, via email, send a message with subject or body 'help' to
> 	tor-relays-request at lists.torproject.org
> 
> You can reach the person managing the list at
> 	tor-relays-owner at lists.torproject.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tor-relays digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: consensus update request (grarpamp)
>    2. Re: not specified families (Aurel W.)
>    3. Re: not specified families (Tor Relays at brwyatt.net)
>    4. Re: not specified families (Damian Johnson)
>    5. New authority (Sebastian Urbach)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 9 Jan 2012 17:45:51 -0500
> From: grarpamp <grarpamp at gmail.com>
> To: tor-relays at lists.torproject.org
> Subject: Re: [tor-relays] consensus update request
> Message-ID:
> 	<CAD2Ti2-Ti1qv4Pb22JsKmpZXMTWPhSPwGyyLtkewYo5Z-U-rJA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> 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 2012-01-09 20:00:00
> Mon Jan  9 22:..:.. UTC 2012
> 
> Is this something that's distributable as a piecemeal
> flood into the net as each router is validated. Some
> sort of client held table so the scale work and
> partitioning is done there with their cpu/disk.
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 10 Jan 2012 00:28:16 +0100
> From: "Aurel W." <aurel.w at gmail.com>
> To: tor-relays at lists.torproject.org
> Subject: Re: [tor-relays] not specified families
> Message-ID:
> 	<CAAG-S2FCxKctVtpPj08Gpkyt5b6hvqO+T2EzauBfUMk=iZv59A at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> > 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 in theory you also have to consider that nodes could get
> compromised and then it is very likely that a whole family is affected
> (may be too paranoid for some).
> 
> I also wonder if it gets harder to identify a real threat, of a
> malicious attacker operating many nodes, if there are so many other
> cases of not-specified families.
> 
> The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem,
> because no one with a malicious attempt would name nodes like that.
> But they are an indication, that there might be a bunch of other
> nodes, without any such strong sings, but which are also operated by
> one single individual. Because obviously, it's a very common mistake
> in configuration.
> 
> There might be feasible techniques to find suspicious groups of
> relays, but with all this non specified families, this would be rather
> pointless.
> 
> aurel
> 
> aurel
> 
> On 9 January 2012 23:39, Javier Bassi <javierbassi at gmail.com> wrote:
> > On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w at gmail.com> 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 controlled by the same person.
> >>
> >> As a first try I mailed to two contact email addresses, but I haven't
> >> got any response.
> >
> > In the end its the same. Relay operators who are willing to place
> > MyFamily in their torrc file are not the ones that are going to try to
> > identify you.
> > 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.
> > Or maybe I'm missing something
> > _______________________________________________
> > tor-relays mailing list
> > tor-relays at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 10 Jan 2012 01:21:20 +0000
> From: "Tor Relays at brwyatt.net" <tor at brwyatt.net>
> To: <tor-relays at lists.torproject.org>
> Subject: Re: [tor-relays] not specified families
> Message-ID: <802693728989435 at jngomktg.net>
> Content-Type: text/plain; charset=UTF-8
> 
> 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 +0100, "Aurel W." <aurel.w at gmail.com> wrote:
> >> 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 in theory you also have to consider that nodes could get
> > compromised and then it is very likely that a whole family is affected
> > (may be too paranoid for some).
> > 
> > I also wonder if it gets harder to identify a real threat, of a
> > malicious attacker operating many nodes, if there are so many other
> > cases of not-specified families.
> > 
> > The "MetallicaFan1, MetallicaFan2,.." nodes might not be a problem,
> > because no one with a malicious attempt would name nodes like that.
> > But they are an indication, that there might be a bunch of other
> > nodes, without any such strong sings, but which are also operated by
> > one single individual. Because obviously, it's a very common mistake
> > in configuration.
> > 
> > There might be feasible techniques to find suspicious groups of
> > relays, but with all this non specified families, this would be rather
> > pointless.
> > 
> > aurel
> > 
> > aurel
> > 
> > On 9 January 2012 23:39, Javier Bassi <javierbassi at gmail.com> wrote:
> >> On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w at gmail.com> 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 controlled by the same person.
> >>>
> >>> As a first try I mailed to two contact email addresses, but I haven't
> >>> got any response.
> >>
> >> In the end its the same. Relay operators who are willing to place
> >> MyFamily in their torrc file are not the ones that are going to try to
> >> identify you.
> >> 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.
> >> Or maybe I'm missing something
> >> _______________________________________________
> >> tor-relays mailing list
> >> tor-relays at lists.torproject.org
> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> > _______________________________________________
> > tor-relays mailing list
> > tor-relays at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 9 Jan 2012 18:00:59 -0800
> From: Damian Johnson <atagar1 at gmail.com>
> To: tor-relays at lists.torproject.org
> Subject: Re: [tor-relays] not specified families
> Message-ID:
> 	<CAJdkzEOp711+5EOscFguTbS3DUDdVi3tEaPOOD3UbUGXtKhihw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> > 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
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 10 Jan 2012 05:04:42 +0100
> From: Sebastian Urbach <sebastian at urbach.org>
> To: tor-relays at lists.torproject.org
> Subject: [tor-relays] New authority
> Message-ID: <20120110040444.AC7731006006A at ccc-hanau.de>
> Content-Type: text/plain; charset="iso-8859-15"
> 
> 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=<fingerprint>".
> 
> Thanks.
> 
> Btw. i respond pretty fast to server / network issues ;-)
> 
> -- 
> Mit freundlichen Gr??en / Yours sincerely
> 
> Sebastian Urbach
> 
> --------------------------------------------------------
> Religion is something left over from the infancy of
> our intelligence, it will fade away as we adopt
> reason and science as our guidelines.
> --------------------------------------------------------
> 
> Bertrand Arthur William Russell (1872-1970),
> British philosopher, logician, mathematician,
> historian, and social critic.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: not available
> URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20120110/f3ea5e96/attachment-0001.pgp>
> 
> ------------------------------
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> End of tor-relays Digest, Vol 12, Issue 9
> *****************************************
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20120110/69b0eb2d/attachment-0001.html>


More information about the tor-relays mailing list