tahoe-lafs/tahoe-lafs
tahoe-lafs
/
tahoe-lafs
2
0
Fork 0
Code Issues Pull Requests 23 Packages Projects Releases 1 Wiki Activity

Removed I2P ticket info because it belongs in a trac ticket

This commit is contained in:
David Stainton 2014-09-05 17:30:39 +00:00 committed by Brian Warner
parent 3126d49d32
commit 4f0b7e0f83
2 changed files with 9 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/anonymity-configuration.rst
View File

@ -233,7 +233,10 @@ I2p software deps here
Configuration
=============
informative configuration info for i2p users
informative configuration info for i2p users goes here
link to tahoe trac ticket regarding client endpoint string
parameter concatenation
Performance and security issues of I2p (if applicable)

28
docs/anonymity-roadmap.rst
View File

@ -8,7 +8,7 @@ Anonymity Development Roadmap
Development phases
==================
1. Use Tor for network connectivity and protect identity of client
1. Use Tor for network connectivity and to protect identity of client
**note:** Client side is endpoint agnostic and server side has TCP endpoint support.
@ -19,29 +19,11 @@ Development phases
* #517
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.
2. Use I2p for network connectivity and to protect identity of client
**Dependencies** ::
* new Tahoe-LAFS trac ticket regarding client endpoint string parameter concatenation
* txi2p
3. endpoint-agnostic Foolscap server side