To get a feeling for how interesting this data might be, we designed an experiment where we deployed 50 relays with the HSDir flag and modified them to log every upload and download of blinded public keys. For example, one could track how many uploaded blinded public keys are never requested or how many client requests for blinded public keys could not be answered. This is expected to increase as soon as a sufficient number of Tor relays start to report data allowing for reliable V3 statistics (hint: remember to keep your Tor relays up-to-date).īy collecting detailed logs of uploads and downloads of blinded public keys, HSDir relays can track many more statistical metrics about V3 onion services and their usage. This means that it is possible to count onion addresses by counting blinded public keys which is already used by the Tor Project to collect statistical information about the number V3 onion services since Tor version 0.4.6.1-alpha (just like they have been doing for V2 for a long time now). However, these changes do not completely stop the hidden service directory from revealing interesting metadata.įirst, it is possible to estimate the number of running onion services by counting the number of uploaded blinded public keys because every onion address translates to exactly one blinded public key per day. Thanks to these improvements, V3 onion services leak much less sensitive information. ), and asks for that blinded public key (here: ek4gJEtlHmwwadLvMNG7tYx /lJuJN1zQl6pMVkGmAcM). onion, the Tor client automatically calculates the current identifier from the onion address and the current date (e.g. So instead of asking the hidden service directory for facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd. With V3 onion services, this is prevented by using key derivation to derive a daily-rotated identifier ("blinded public key"). However, clients still need to ask the directory for information about a specific onion address, which would again allow mass collection of onion addresses. Clients can always decrypt that data with the key embedded in the. Since the V3 address is itself a public key, all the data uploaded to the hidden service directory can be encrypted. V3 uses encryption and key derivation to address this issue. ![]() Note that collecting and probing V2 onion addresses via HSDir relays is considered malicious behavior and sanctioned by Tor’s bad-relays team. ![]() For V2 onion services, the data published in the hidden service directory is uploaded in plain text, meaning that the Tor relays with the HSDir flag can learn a lot of information about a small fraction of running V2 onion services (most importantly the onion address) every day. To protect the privacy of onion service users, the hidden service directory is a distributed hash table formed by all Tor relays which possess the HSDir flag. ![]() Its purpose is to provide the information needed to connect to a specified onion address (just like the DNS system does for regular domain names). The main reason behind this change is tied to a key component of all onion services, the hidden service directory. V3 onion addresses have 56 characters instead of 16 (because they contain a full ed25519 public key, not just the hash of a public key), meaning that migrating from V2 to V3 requires all users to learn/remember/save a new onion address address. The most obvious difference between V2 and V3 onion services is the different address format. Aware of those limitations, our research group at the Institute of Network and Security at JKU Linz conducted an experiment that extracts information about how V3 onion services are being used from the Tor network. This post will discuss the most important privacy improvements provided by V3 onion services as well as their limitations. With the deprecation of V2 onion services right around the corner, it is a good time to talk about V3 onion services.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |