[tor-commits] [obfsproxy/master] Elaborate on server's behaviour.

asn at torproject.org asn at torproject.org
Tue Jul 15 12:23:06 UTC 2014


commit 081e943987fad482786b1fa6fe3653672b22227d
Author: Philipp Winter <phw at torproject.org>
Date:   Sat Mar 1 22:14:18 2014 +0100

    Elaborate on server's behaviour.
    
    In particular, discuss strategies which servers should implement if clients
    cannot authenticate.  Otherwise, malicious clients could run computation-based
    or memory-based denial-of-service attacks.  This problem was reported by
    Yawning Angel.
    
    This should fix <https://bugs.torproject.org/11092>.
---
 doc/scramblesuit/scramblesuit-spec.txt |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/doc/scramblesuit/scramblesuit-spec.txt b/doc/scramblesuit/scramblesuit-spec.txt
index de6b778..1de6263 100644
--- a/doc/scramblesuit/scramblesuit-spec.txt
+++ b/doc/scramblesuit/scramblesuit-spec.txt
@@ -35,10 +35,13 @@
     secret should thwart active probing attacks.
 
     As stated in the research paper [1], a server only replies to a client if
-    the client can prove knowledge of the shared secret.  If a client sends
-    data which lacks this knowledge, the server MUST NOT reply.  It MAY
-    terminate the connection if the client could not prove knowledge of the
-    shared secret after a timeout has passed.
+    the client can prove knowledge of the shared secret.  As long as clients
+    cannot prove knowledge of the shared secret, servers MUST NOT reply.  If
+    authentication did not succeed after 1532 bytes have been received, the
+    server SHOULD stop processing incoming data to prevent denial-of-service
+    attacks.  The server MAY close the TCP connection.  Alternatively, the
+    server MAY proceed to accept data but it SHOULD stop buffering or
+    processing the data, thus effectively ignoring the client.
 
 2.1 UniformDH Handshake
 





More information about the tor-commits mailing list