Re: [tor-relays] MyFamily

[Matt Palmer]

On Mon, May 15, 2023 at 10:18:29AM -0400, denny.obre...@a-n-o-n-y-m-e.net wrote:
> trinity pointard  wrote ..
> > For an easy example, let's imagine that we let any relay put itself
> > into any family.  Now suppose the attacker starts three relays A1, A2,
> > and A3.  Then, since nothing stops them, they put A1 into a family
> > with every relay on the network, except for A2 and A3.  Now, any time
> > a user (randomly) selects A1, they will find that the only other
> > relays they can use on that circuit are A2 and A3; this will build a
> > completely attacker-controlled path, they will get no privacy.
> 
> How can you find a family with every relay on the network?  According to
> the proposal, the largest family has 270 members and, according to Tor
> metrics, they are about 2000 exit relays.  Even assuming an attacker
> controls A1 and A2, both falsely belonging to two different families with
> 250 members each (assuming all exit relays), the attacker would just
> increase his chances of having his A3 exit relay to be selected from
> 1/2000 to 1/1500.  Not nothing, but not a large advantage either.

I presumed the attacker would create a new family, and declare all other
relays members of that family.

> The problem you are describing is actually one that is possible RIGHT NOW
> with MyFamily.  An attacker CAN list all relay fingerprints he can find in
> its MyFamily except his relays.

Except that the family won't be recognised as containing all those other
relays because the other relays don't include the attacker's relay A1 in
their MyFamily declaration.

- Matt

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

Re: [tor-relays] MyFamily

[denny . obreham]

trinity pointard  wrote ..
> . It's not as easy as having a unique ID, you need to make sure a
> relay can't spoof being part of a family, that's why it requires a two
> way relationship for now, and will probably use some form of signature
> in the future.

Why not take advantage of the proof entry of ContactInfo? ( 
https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#proof )

All you need to do is to add a file like 
https://example.com/.well-known/tor-relay/family-rsa-fingerprint.txt (uri-rsa) 
or DNS TXT record family-fingerprint.example.com (dns-rsa) which would contain 
one of the relay fingerprints of the family (the same one for all relays). The 
name is thus unique and you can easily check if the family name and 
corresponding relay fingerprint are linked to the same relay operator. The only 
drawback is if the chosen relay for the family name is removed from the network 
then a new one will have to be chosen and all the MyFamily values changed on 
every relay. Most likely a very rare event.

Heck, a file https://example.com/.well-known/tor-relay/rsa-fingerprint.txt has 
already the same content as MyFamily. (Which I am guessing is one way "Alleged 
Family Members" are identified on Tor metrics.)

_

> For an easy example, let's imagine that we let any relay put itself
> into any family.  Now suppose the attacker starts three relays A1, A2,
> and A3.  Then, since nothing stops them, they put A1 into a family
> with every relay on the network, except for A2 and A3.  Now, any time
> a user (randomly) selects A1, they will find that the only other
> relays they can use on that circuit are A2 and A3; this will build a
> completely attacker-controlled path, they will get no privacy.

How can you find a family with every relay on the network? According to the 
proposal, the largest family has 270 members and, according to Tor metrics, 
they are about 2000 exit relays. Even assuming an attacker controls A1 and A2, 
both falsely belonging to two different families with 250 members each 
(assuming all exit relays), the attacker would just increase his chances of 
having his A3 exit relay to be selected from 1/2000 to 1/1500. Not nothing, but 
not a large advantage either.

The problem you are describing is actually one that is possible RIGHT NOW with 
MyFamily. An attacker CAN list all relay fingerprints he can find in its 
MyFamily except his relays. If he could only list ONE family name, he could 
only spoof it with the most popular family name used (assuming family name 
uniqueness is not enforced and more than one relay operator use the same name). 
But it is impossible that all [good] relay operators use the same family name, 
even if they would be allowed to select one as simple as "Smith".

MyFamily with a single name seems both a very tiny spoofing problem AND an 
improvement over the current configuration.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] MyFamily

[Nick Mathewson]

On Mon, May 15, 2023 at 5:21 AM Matt Palmer  wrote:
>
> On Sat, May 13, 2023 at 12:55:17PM -0400, denny.obre...@a-n-o-n-y-m-e.net 
> wrote:
> > This has probably been addressed before but why isn't the MyFamily value
> > just a single, unique ID?
> >
> > If I have the relays with the fingerprints "John", "Jane", and "Alice" and
> > I want to add "Bob", wouldn't it be simpler (and more logical) to add the
> > unique MyFamily "Smith" to each torrc file than listing all fingerprints?
>
> I believe the reason for the current setup is to prevent randos from adding
> themselves to your family of relays, and then causing problems.

That's correct: if an attacker can add their relay to a family without
the rest of the family's consent, they can use that to influence
routing and do some kinds of path-selection attacks.

For an easy example, let's imagine that we let any relay put itself
into any family.  Now suppose the attacker starts three relays A1, A2,
and A3.  Then, since nothing stops them, they put A1 into a family
with every relay on the network, except for A2 and A3.  Now, any time
a user (randomly) selects A1, they will find that the only other
relays they can use on that circuit are A2 and A3; this will build a
completely attacker-controlled path, they will get no privacy.

That said, there's an open proposal to try to make it so relays can
use a cryptographic identifier instead of a unique ID or a list:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/321-happy-families.md
I'd be curious to know whether relay operators think this proposal
would be usable for them; when I first circulated it, I didn't get a
lot of feedback.

(Oh, I see that Trinity has mentioned this too.  Hi, Trinity!)

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

Re: [tor-relays] MyFamily

[trinity pointard]

> This has probably been addressed before but why isn't the MyFamily value just 
> a single, unique ID?

There is a proposal to have some way of doing that in the future, but
that proposal isn't implemented
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/321-happy-families.md
. It's not as easy as having a unique ID, you need to make sure a
relay can't spoof being part of a family, that's why it requires a two
way relationship for now, and will probably use some form of signature
in the future.

> What do you do when you have 50 relays and want to add or remove a relay? You 
> must modify 50 torrc files and restart all 50 relays? That seems tedious and 
> unnecessary.

Sadly, yes it is. You can reload the relays instead of restarting
them, which is somewhat better but still not great. On thing that can
help is using the %include feature of torrc to have your MyFamily line
in a distinct file you can easily copy around. That's not great, but
still easier/safer than editing a configuration file automatically.

regards,

trinity-1686a

On Mon, 15 May 2023 at 11:22, Matt Palmer  wrote:
>
> On Sat, May 13, 2023 at 12:55:17PM -0400, denny.obre...@a-n-o-n-y-m-e.net 
> wrote:
> > This has probably been addressed before but why isn't the MyFamily value
> > just a single, unique ID?
> >
> > If I have the relays with the fingerprints "John", "Jane", and "Alice" and
> > I want to add "Bob", wouldn't it be simpler (and more logical) to add the
> > unique MyFamily "Smith" to each torrc file than listing all fingerprints?
>
> I believe the reason for the current setup is to prevent randos from adding
> themselves to your family of relays, and then causing problems.
>
> - Matt
>
> ___
> 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] [Important] A call for more long running bridges, especially with OBFS IAT-Mode set to 1 or 2.

[Fran via tor-relays]

Hey,

the paper is from August 2018 (if I looked at the correct one), not so 
recent :)


And e. g. Philipp Winter questions the usefulness of iat_mode:

> substantial performance penalty for a dubious and poorly understood 
privacy gain


https://lists.torproject.org/pipermail/tor-relays/2021-February/019370.html


I personally leave my bridges as they are, without iat_mode.


Best,

Fran










On 5/12/23 13:34, George Hartley via tor-relays wrote:

Hello dear relay and bridge hosts,

recently a paper was published, describing a traffic confirmation attack 
called DeepCorr, which works against Tor users and as such, also hidden 
services.


The attack allegedly had success rates of up to *96% percent*.

It is being worked on and listed here as a separate ticket:

https://forum.torproject.net/t/tor-dev-critical-deepcorr-traffic-confirmation-attack/6720
 


Until mitigations have been merged into the Tor codebase, I kindly ask 
you, the driving force behind the network, to set up more bridges with 
"iat-mode" enabled and set to "1" or "2" - the paper stated that it was 
significantly harder to launch successful attacks against clients using 
OBFS4 bridges with timing obfuscation enabled, which is what "iat-mode" 
really is.


*In a nutshell*, the measure of IAT is the average (or the arithmetic 
mean) between network packets arriving at a host over a period of time, 
of the times between packets arriving at a host over a period of time, 
which you can also call latency.


For security reasons such as defeating DPI and similar network analysis 
techniques, OBFS4, while at the same time encrypting and making your 
traffic look like regular TLS traffic, it also
offers to try and obfuscate the IAT and packet size by inserting random 
padding bytes.


For you guys or girls with programming skills or the ability to read and 
understand code, here is the responsible code:


https://github.com/Yawning/obfs4/blob/40245c4a1cf221395c59d1f4bf274127045352f9/transports/obfs4/obfs4.go#L481
 


I vote for a fair 50 / 50 distribution of bridges with "iat-mode=1" and 
"iat-mode=2", even though while IAT mode 2, also called the "paranoid" 
mode by the author of the code above, may be more effective.


Dear *clients*, you can already enable timing-obfuscation in *one way*, 
by editing your bridge-line and setting iat-mode from "0" to either "1" 
or "2" - please be aware that this will only enable timing-obfuscation 
in one way, the bridge needs to support it too to get packet timing 
obfuscated in both ways.


Dear *bridge operators*, all it takes is a simple tor configuration file 
change:


ServerTransportOptions obfs4 iat-mode=1

or

ServerTransportOptions obfs4 iat-mode=2

Your bridge key will very likely stay the same, although I /do not/ have 
the infrastructure to try this out right now.


It is and has been *very hard* to find *reliable* OBFS4 bridges which 
also support timing obfuscation, for over a year now - *please consider 
changing your bridge configuration in order to possibly help clients and 
hidden services evade timing related attacks such as DeepCorr*.


Yours truly,
George Hartley

___
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] MyFamily

[Matt Palmer]

On Sat, May 13, 2023 at 12:55:17PM -0400, denny.obre...@a-n-o-n-y-m-e.net wrote:
> This has probably been addressed before but why isn't the MyFamily value
> just a single, unique ID?
> 
> If I have the relays with the fingerprints "John", "Jane", and "Alice" and
> I want to add "Bob", wouldn't it be simpler (and more logical) to add the
> unique MyFamily "Smith" to each torrc file than listing all fingerprints?

I believe the reason for the current setup is to prevent randos from adding
themselves to your family of relays, and then causing problems.

- Matt

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