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

> From: tor-relays-request@xxxxxxxxxxxxxxxxxxxx
> Subject: tor-relays Digest, Vol 12, Issue 9
> To: tor-relays@xxxxxxxxxxxxxxxxxxxx
> Date: Tue, 10 Jan 2012 12:00:02 +0000
>
> Send tor-relays mailing list submissions to
> tor-relays@xxxxxxxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxxx
>
> You can reach the person managing the list at
> tor-relays-owner@xxxxxxxxxxxxxxxxxxxx
>
> 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 speci fied 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@xxxxxxxxx>
> To: tor-relays@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-relays] consensus update request
> Message-ID:
> <CAD2Ti2-Ti1qv4Pb22JsKmpZXMTWPhSPwGyyLtkewYo5Z-U-rJA@xxxxxxxxxxxxxx>
> 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 b efore
> 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@xxxxxxxxx>
> To: tor-relays@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-relays] not specified families
> Message-ID:
> <CAAG-S2FCxKctVtpPj08Gpkyt5b6hvqO+T2EzauBfUMk=iZv59A@xxxxxxxxxxxxxx>
> 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
> > nic k 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.
>
> The re 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@xxxxxxxxx> wrote:
> > On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w@xxxxxxxxx> 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 tor rc 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@xxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxx>
> To: <tor-relays@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [tor-relays] not specified famili es
> Message-ID: <802693728989435@xxxxxxxxxxxx>
> 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@xxxxxxxxx> 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.
> >
> & gt; aurel
> >
> > aurel
> >
> > On 9 January 2012 23:39, Javier Bassi <javierbassi@xxxxxxxxx> wrote:
> >> On Mon, Jan 9, 2012 at 7:13 PM, Aurel W. <aurel.w@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> > _______________________________________________
> > tor-relays mailing list
> > tor-relays@xxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxx>
> To: tor-relays@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-relays] not specified families
> Message-ID:
> <CAJdkzEOp711+5EOscFguTbS3DUDdVi3tEaPOOD3UbUGXtKhihw@xxxxxxxxxxxxxx>
> 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@xxxxxxxxxx>
> To: tor-relays@xxxxxxxxxxxxxxxxxxxx
> Subject: [tor-relays] New authority
> Message-ID: <20120110040444.AC7731006006A@xxxxxxxxxxxx>
> Conten t-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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
> End of tor-relays Digest, Vol 12, Issue 9
> *****************************************