[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3888: Handling Tor and i2p in NURLs

[Tahoe-LAFS]

#3888: Handling Tor and i2p in NURLs
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:
         Type:  defect    |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------

Comment (by itamarst):

 More notes: the way we've decided to implement listening (#3902) is by
 sharing the Foolscap TCP port, and therefore the Foolscap listening and
 configuration-parsing logic, specifically `tub.port` and `tub.location`.

 For the moment, then, the actual logic for _listening_ on these ports is
 implemented by Foolscap, there is no need for HTTP-specific code. However,
 we do need custom NURL generation for Tor (the `.onion` domain) and I2P.
 This can be done post-#3902, and sounds like we decided on `pb://` for Tor
 and `pb+i2p://` for I2P. Even though the Tor endpoint has same URL
 structure as normal endpoint, it still needs custom code to generate it.

 In the long term we will need to reimplement the listening logic, but that
 might take a while due to need for backwards compatibility.

 On the _client_ side we need two things:

 1. At minimum, HTTP client code that understands `.onion` URLs (#3910).
 2. An HTTP-specific Tor policy for additional privacy, specifically to
 address timing analysis attacks, which would work both with `.onion` and
 public servers. For example, the Tor Browser has a bunch of policies about
 how it routes to different domains and to a specific domain to reduce this
 risk. This is probably a long-term thing (#3911).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3888#comment:9>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage