ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-04-07 10:56:49 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Changes required for safe txi2p use

Browse Source
This commit is contained in:
str4d 2014-09-05 01:14:22 +00:00 committed by Brian Warner
parent 832a798374
commit f3bc270a4e
1 changed files with 19 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
docs/anonymity-roadmap.rst
View File

@ -22,6 +22,25 @@ Development phases
2. Use I2p for network connectivity and protect identity of client
* txi2p
* Add "endpoint parameters" to Tahoe
* Servers provide the minimum client endpoint string required to connect to them:
* ``tcp:example.org:1337``
* ``ssl:example.org:443``
* ``i2p:longstring.b32.i2p``
* Clients may need to extend the strings with client-specific per-type parameters in order to successfully connect:
* ``tcp:example.org:1337:timeout=60``
* ``ssl:example.org:443:caCertsDir=/etc/ssl/certs``
* ``i2p:longstring.b32.i2p:tunnelNick=tahoe:inport=10000``
* These should be set in ``tahoe.cfg``:
* ``[node]clientEndpointParams = tcp:timeout=60,ssl:caCertsDir=/etc/ssl/certs,i2p:tunnelNick=tahoe:inport=10000``
* Tahoe parses, keeps an internal map, applies the relevant params to a client endpoint string before connecting
* Client endpoint string whitelisting
* Server publishes an endpoint string for a client to connect to
* A malicious server could publish strings containing client-specific parameters that compromise the user
* Unsure what parameters could actually be used maliciously on their own, but definitely possible in concert with other attacks.
* The client should not accept strings that contain client-specific parameters
* How to tell the difference? Tahoe can't keep a list of everything that is safe.
* Maybe an endpoint API method that takes a client endpoint string and returns a safe one.
3. endpoint-agnostic Foolscap server side