[tor-commits] [torspec/master] Defang TLS UKS attacks in tor-spec.txt

[nickm at torproject.org]

commit 426e9ac1069ee843000aaeed9260ba4c9733af00
Author: Nick Mathewson <nickm at torproject.org>
Date:   Tue Mar 4 10:23:40 2014 -0500

    Defang TLS UKS attacks in tor-spec.txt
    
    Our implementations disable session resumption, and don't send
    AUTHENTICATE before checking CERTS.  It turns out that these are
    pretty important: see discussion of "triple handshake" and related
    UKS-enabled attacks at
    
    https://lists.torproject.org/pipermail/tor-dev/2014-March/006372.html
    
    Basically, session resumption plus renegotiation enables the triple-
    handshake attack.  And sending an AUTHENTICATE cell before checking
    the CERTS cell would lead to sending the wrong SID field in the
    AUTHENTICATE cell, which would whittle our defense there even further.
---
 tor-spec.txt |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tor-spec.txt b/tor-spec.txt
index c3b96a3..604a1e7 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -355,6 +355,12 @@ see tor-design.pdf.
    less than HASH_LEN bits.  Responders SHOULD NOT select any SSLv3
    ciphersuite other than the DHE+3DES suites listed above.
 
+2.2. TLS security considerations
+
+   Implementations MUST NOT allow TLS session resumption -- it can
+   exacerbate some attacks (e.g. the "Triple Handshake" attack from
+   Feb 2013), and it plays havoc with forward secrecy guarantees.
+
 3. Cell Packet format
 
    The basic unit of communication for onion routers and onion
@@ -645,6 +651,10 @@ see tor-design.pdf.
    signature.  The server MUST ignore any extra bytes in the signed
    data after the SHA256 hash.
 
+   Initiators MUST NOT send an AUTHENTICATE cell before they have
+   verified the certificates presented in the responder's CERTS
+   cell, and authenticated the responder.
+
 4.5. NETINFO cells
 
    If version 2 or higher is negotiated, each party sends the other a