Opened 3 months ago

Closed 7 days ago

Last modified 7 days ago

#22791 closed defect (invalid)

Prop 224 encrypted public key

Reported by: Dbryrtfbcbhgf Owned by:
Priority: High Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In prop 224 the "HS-DESC-FIRST-LAYER" is is encrypted to prevent a attacker from discovering the onion address of the hidden service, but even though it is encrypted it may still be possible to log the ciphertext of the "HS-DESC-FIRST-LAYER" every single time someone visits The hidden service. Through that they can determine how many people are visiting the hidden service, using that information on how many people are visiting the service, a attacker may be able to determine what type of site it is or use there nodes "researchers have set up nodes to capture the .onion addresses of hidden services" that they own to block traffic to any of those hidden services. The HS-DESC-FIRST-LAYER " Ciphertext" needs to be padded/obfuscated so it is different every single time a new user tries to decrypt it.

Child Tickets

Change History (4)

comment:1 Changed 3 months ago by dgoulet

Resolution: invalid
Status: newclosed

There seems to be many confusion here.

The HS-DESC-FIRST-LAYER is not encrypted differently per client. If you don't know the onion address, you can't log the ciphertext _from_ the descriptor because you can't get it in the first place without the onion address. So the attackers move here is to run a bunch of HSDir and log all ciphertext it sees. But because that ciphertext is always the same, I don't see how you would correlate this with the number of clients visiting...? You can do that by counting the number of descriptor request you get for that descriptor and extrapolating by 3 (because 3 directories by default).

Furthermore, that layer *IS* padded but it is ultimately to hide if a onion address is using client authorization and the number of introduction points. See section 2.5.1.1.:

   Before encryption the plaintext is padded with NUL bytes to the nearest
   multiple of 10k bytes.

comment:2 Changed 2 months ago by Dbryrtfbcbhgf

Resolution: invalid
Status: closedreopened

Thanks for the information.

If you discover what "ciphertext = .onion" can a Rondevoo points block access to ciphertext that they have discovered.

Example. ciphertext{ YTitcitfyitcyyitvygiviguuivg} = securitysitegvj.onion} can the Rondevoo node Block all connections trying to go to [YTitcitfyitcyyitvygiviguuivg]

You can close the ticket after this it's answered thank you.

comment:3 Changed 7 days ago by nickm

Resolution: invalid
Status: reopenedclosed

no; the rendezvous node shouldn't be able to do that. The hidden service directory can block, though, but only if it knows the original .onion address. That's still something that needs to get detected via regular scanning.

comment:4 in reply to:  3 Changed 7 days ago by Dbryrtfbcbhgf

Replying to nickm:

no; the rendezvous node shouldn't be able to do that. The hidden service directory can block, though, but only if it knows the original .onion address. That's still something that needs to get detected via regular scanning.

Thanks for the explanation nickm.

Note: See TracTickets for help on using tickets.