From 9cd227e41bc65e85f08df9875c688cfbcb4db431 Mon Sep 17 00:00:00 2001 From: Nick Daly Date: Sat, 17 Mar 2012 15:51:28 -0500 Subject: [PATCH] Added false-flag overview. --- ugly_hacks/santiago/README.rst | 24 ++++++++++++++++++++++++ ugly_hacks/santiago/test_santiago.py | 8 ++++---- 2 files changed, 28 insertions(+), 4 deletions(-) diff --git a/ugly_hacks/santiago/README.rst b/ugly_hacks/santiago/README.rst index cc1b62dce..923b73cf5 100644 --- a/ugly_hacks/santiago/README.rst +++ b/ugly_hacks/santiago/README.rst @@ -350,6 +350,25 @@ list of recently-proxied-requests so that no box sends the same request to its friends within a time-range. Might we need to look into other request proxying methods when the DHT comes up? +False Flags / False Friends +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:TODO: Add unit tests for these behaviors. + +Since we allow request proxying, an attacker (C) who knows where my Santiago (B) +is located and has captured a real request from a trusted party (A) can later +forward that request to me, again, for the fun of it. However, requiring both +the proxier and client to be trusted means that such falsely forwarded requests +will go unanswered. + +However, if the key is compromised, an attacker could modify the message's +"reply-to" header to allow communication with an untrusted third party. +Santiago cannot protect against this manner of attack because the data we use to +validate the request (the key) is compromised. We can't enforce a reverse-DNS +style callback very well, because there's no guarantee we can reach the client +in the first place. We could try, but I don't know how much trust it would add +to the system beyond that which we can guarantee by signed messages alone. + Mitigations =========== @@ -391,6 +410,11 @@ Design Questions bit. That we don't allow untrusted connections is an incredible limitation on the routing system. +:Reverse DNS: Should we check with the original requester before replying? What + if we can't reach that requester outside of the reply-to address they sent? + Verifying the requester's identity by their self-reported address seems to + add little confidence to the requester's identity. + Functional Questions -------------------- diff --git a/ugly_hacks/santiago/test_santiago.py b/ugly_hacks/santiago/test_santiago.py index 20a298b9f..b16433b51 100644 --- a/ugly_hacks/santiago/test_santiago.py +++ b/ugly_hacks/santiago/test_santiago.py @@ -56,10 +56,10 @@ class SantiagoTest(unittest.TestCase): class TestServerInitialRequest(SantiagoTest): """Test how the Santiago server replies to initial service requests. - TODO: tests for: - - (normal serving + proxying) * (learning santiagi + not learning) - + TODO: Add a mock listener to represent A. + TODO: Transform the data structure tests into the mock-response tests. + TODO tests: (normal serving + proxying) * (learning santiagi + not learning) + """ def test_acknowledgement(self): """If B receives an authorized request, then it replies with a location.