Opened 2 years ago

Closed 2 years ago

#23641 closed defect (wontfix)

prop224: Fake client auth lines do not actually provide obfuscation

Reported by: asn Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version: Tor: 0.3.2.1-alpha
Severity: Normal Keywords: prop224 tor-hs
Cc: Actual Points:
Parent ID: Points:
Reviewer: asn Sponsor:

Description (last modified by asn)

prop224 spec says:

   If client auth is disabled, fake data is placed in each of the fields below
   to obfuscate whether client authorization is enabled.

and

If client authorization is disabled, the fields here can be populated with random
      data of the right size (that's 8 bytes for 'client-id', 16 bytes for 'iv'
      and 16 bytes for 'encrypted-cookie' all encoded with base64).

However, after second thinking, those fake client auth lines don't actually confuse the adversaries we care about:

a) HSDir adversary with no onion address: This adversary does not learn whether client auth is enabled because of the desc padding anyway.

b) HSDir adversary with onion address: This adversary can decrypt the first desc layer, and then attempt to decrypt the second layer with no client auth info. If second layer decrypts, there is no client auth. If decryption fails, client auth is enabled.

Hence for both adversaries (a) and (b), the fact that we add fake client auth lines does not matter. Perhaps we could rip that feature out (get_fake_auth_client_str() etc.)

The annoying thing here is that currently we actually require client auth lines since: T1N(str_desc_auth_client, R3_DESC_AUTH_CLIENT, GE(3), NO_OBJ).

As a first step here it might be a good idea to change the T1N() to T0N() and make sure that everything run ssmoothly when no client auth lines are provided.

Child Tickets

Change History (9)

comment:1 Changed 2 years ago by nickm

One thing that these fake lines do hide is the _number_ of real auth-client lines?

comment:2 Changed 2 years ago by asn

Description: modified (diff)

comment:3 in reply to:  1 ; Changed 2 years ago by asn

Replying to nickm:

One thing that these fake lines do hide is the _number_ of real auth-client lines?

That's true. We should probably continue adding fake lines if auth is actually enabled.
But they offer nothing if auth is disabled.

comment:4 in reply to:  3 Changed 2 years ago by dgoulet

Replying to asn:

Replying to nickm:

One thing that these fake lines do hide is the _number_ of real auth-client lines?

That's true. We should probably continue adding fake lines if auth is actually enabled.
But they offer nothing if auth is disabled.

Is it really true for (a) here? We do padding by multiple of 10k bytes so if the normal descriptor is lets say 23k, it is padded to 30k. But if client auth is enabled, it could go to something like 32k thus 40k padded.

If I don't have an onion address for that descriptor, I can still say that "oh this descriptor here as client auth" just because the size compared to the majority of them is different. Any descriptor diverging in size either has *many* IPs or/and client auth basically. Maybe that unknown is enough to justify not adding fake client, unsure.

Thus, I kind of think having this concept of fake client for every descriptor is useful because it makes them "look all alike" in terms of size for observers who don't have the .onion.

If you *do* have the .onion, the number of valid client will be obfuscated so I do see a gain for both situations?

I do agree on the change of T0N() so we have more room for change.

comment:5 Changed 2 years ago by dgoulet

Owner: set to dgoulet
Status: newaccepted

comment:6 Changed 2 years ago by dgoulet

Reviewer: asn
Status: acceptedneeds_review

Branch: bug23641_032_01

I've removed the code that adds fake "auth-client" and the decoding test pass no problem.

comment:7 Changed 2 years ago by asn

Status: needs_reviewneeds_information

Do we think this is still worth doing even tho we will not be able to remove str_desc_auth_key and str_desc_auth_type since the code requires it? Seems like we are kinda commited to some sort of fake auth data anyway, so perhaps we could keep one line of fake auth-client too if we need to?

comment:8 Changed 2 years ago by dgoulet

Yeah either we keep auth line or we do some trick to not require that entire section at all.... Seems we are committed so maybe this whole patch is not needed... ?

comment:9 Changed 2 years ago by asn

Resolution: wontfix
Status: needs_informationclosed

I'm fine with not implementing this ticket, since it does not seem to be that useful due to comment:7.

I'm gonna close it but feel free to open it if you disagree!

Note: See TracTickets for help on using tickets.