From b2fbdad1e3026df2e44f341c9265e2fe82c051eb Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 5 Sep 2014 01:14:22 +0000 Subject: [PATCH] Changes required for safe txi2p use --- docs/anonymity-roadmap.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/anonymity-roadmap.rst b/docs/anonymity-roadmap.rst index 56aff644..2e2a7866 100644 --- a/docs/anonymity-roadmap.rst +++ b/docs/anonymity-roadmap.rst @@ -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 -- 2.45.2