Hacks to reduce Tor's initial download on slow Internet, sacrificing privacy?
Hi everyone, Is there a way right now to get Tor hidden service functionality (hosting a hidden service, connecting to hidden services) on a connection where the Internet is so slow and unreliable that the initial download of network information currently takes ~forever, provided one is willing to sacrifice metadata protection? Is there a way to download, say, 100x less network information on startup and still effectively host and connect to hidden services? Or is there a way to hardcode network information with the client, since that can be installed before going into the slow Internet zone, from a CDN that is less impacted, or from a source on the local network? (I read that this is how Tor worked in the past?) The context is the following: I have a p2p messaging app that uses Tor and hidden services (Quiet) in a way similar to Ricochet or Onionshare. I'm going to a conference where last year the Internet was so slow that Tor's initial download of network information took too long and kept timing out, rendering Quiet unusable. The Internet was, however, fairly reliable and usable for e.g. web browsing and messaging. I'd like to be able to use Quiet at this conference. It would be used purely as a demo for a few days, and we could warn everyone that our use of Tor did not offer its typical security properties. (Then in future years we might support p2p connectivity over local wifi, like Briar does!) My understanding is that the network information download step is to protect users against epistemic attacks. My intuition is that for situations where this doesn't matter there is some way to use Tor with a small subset of the network information and that the initial download could be skipped. Is this true? What's the best way to do it in the Tor client we ship? (I'm familiar with the Walking Onions paper, but looking for something that is ready now. There isn't already an implementation of Walking Onions, is there?) Thanks! Holmes
On 5/3/23 17:24, Holmes Wilson wrote:
Hi everyone,
Is there a way right now to get Tor hidden service functionality (hosting a hidden service, connecting to hidden services) on a connection where the Internet is so slow and unreliable that the initial download of network information currently takes ~forever, provided one is willing to sacrifice metadata protection?
Is there a way to download, say, 100x less network information on startup and still effectively host and connect to hidden services? Or is there a way to hardcode network information with the client, since that can be installed before going into the slow Internet zone, from a CDN that is less impacted, or from a source on the local network? (I read that this is how Tor worked in the past?)
The context is the following:
I have a p2p messaging app that uses Tor and hidden services (Quiet) in a way similar to Ricochet or Onionshare. I'm going to a conference where last year the Internet was so slow that Tor's initial download of network information took too long and kept timing out, rendering Quiet unusable. The Internet was, however, fairly reliable and usable for e.g. web browsing and messaging. I'd like to be able to use Quiet at this conference. It would be used purely as a demo for a few days, and we could warn everyone that our use of Tor did not offer its typical security properties. (Then in future years we might support p2p connectivity over local wifi, like Briar does!)
My understanding is that the network information download step is to protect users against epistemic attacks. My intuition is that for situations where this doesn't matter there is some way to use Tor with a small subset of the network information and that the initial download could be skipped.
Is this true? What's the best way to do it in the Tor client we ship?
If you include a Tor data directory with a fresh set of the cached microdesc consensus and microdesc descriptor documents in your app distribution, and *also* hack REASONABLY_LIVE_TIME in src/feature/nodelist/networkstatus.c to be as long as you expect that release to be published, I think this gets you what you want. The default is 24 hours, which means that clients will accept these cached documents for up to 24 hours as valid, before blocking everything to download a new one. So you can hack this value to be much higher (at the cost of increased risk to clients from being fed a stale consensus continually), and refresh your download files to include new documents, once per time window. I think this will work, but I would not be surprised if you hit a few other "safety" checks that are elsewhere in the codebase, other than that #define, that you also have to change.
(I'm familiar with the Walking Onions paper, but looking for something that is ready now. There isn't already an implementation of Walking Onions, is there?)
No. Also arti-relay impl will mean fewer relays in the consensus, because of multicore support. It will also probably mean better consensus diff support. But that isn't done either. -- Mike Perry
This is what I was looking for. Thanks! On Mon, May 8, 2023, 4:56 PM Mike Perry <mikeperry@torproject.org> wrote:
On 5/3/23 17:24, Holmes Wilson wrote:
Hi everyone,
Is there a way right now to get Tor hidden service functionality (hosting a hidden service, connecting to hidden services) on a connection where the Internet is so slow and unreliable that the initial download of network information currently takes ~forever, provided one is willing to sacrifice metadata protection?
Is there a way to download, say, 100x less network information on startup and still effectively host and connect to hidden services? Or is there a way to hardcode network information with the client, since that can be installed before going into the slow Internet zone, from a CDN that is less impacted, or from a source on the local network? (I read that this is how Tor worked in the past?)
The context is the following:
I have a p2p messaging app that uses Tor and hidden services (Quiet) in a way similar to Ricochet or Onionshare. I'm going to a conference where last year the Internet was so slow that Tor's initial download of network information took too long and kept timing out, rendering Quiet unusable. The Internet was, however, fairly reliable and usable for e.g. web browsing and messaging. I'd like to be able to use Quiet at this conference. It would be used purely as a demo for a few days, and we could warn everyone that our use of Tor did not offer its typical security properties. (Then in future years we might support p2p connectivity over local wifi, like Briar does!)
My understanding is that the network information download step is to protect users against epistemic attacks. My intuition is that for situations where this doesn't matter there is some way to use Tor with a small subset of the network information and that the initial download could be skipped.
Is this true? What's the best way to do it in the Tor client we ship?
If you include a Tor data directory with a fresh set of the cached microdesc consensus and microdesc descriptor documents in your app distribution, and *also* hack REASONABLY_LIVE_TIME in src/feature/nodelist/networkstatus.c to be as long as you expect that release to be published, I think this gets you what you want.
The default is 24 hours, which means that clients will accept these cached documents for up to 24 hours as valid, before blocking everything to download a new one.
So you can hack this value to be much higher (at the cost of increased risk to clients from being fed a stale consensus continually), and refresh your download files to include new documents, once per time window.
I think this will work, but I would not be surprised if you hit a few other "safety" checks that are elsewhere in the codebase, other than that #define, that you also have to change.
(I'm familiar with the Walking Onions paper, but looking for something that is ready now. There isn't already an implementation of Walking Onions, is there?)
No. Also arti-relay impl will mean fewer relays in the consensus, because of multicore support. It will also probably mean better consensus diff support. But that isn't done either.
-- Mike Perry _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (3)
-
Holmes Wilson -
Holmes Wilson -
Mike Perry