r16215@tombo: nickm | 2008-06-12 18:39:03 -0400

 Implement code to manually force the OpenSSL client cipher list to match the one recommended in proposal 124, *even if* we do not know all those ciphers.  This is a bit of a kludge, but it is at least decently well commented.


svn:r15173

2 files changed, 7 insertions, 4 deletions

diff --git a/doc/TODO b/doc/TODO
index 3e512e95d2..4532735a02 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -105,10 +105,10 @@ N   - Take our draft research proposal for how to safely collect and
       . Test
     - More back-end work:
 N     - Additional TLS-camouflage work (spoofing FF cipher suite, etc.)
-        - spoof the cipher suites
-        - spoof the extensions list
+        o spoof the cipher suites
+        o spoof the extensions list
         - red-team testing (a.k.a, look at a packet dump and compare),
-        - investigate the feasibility of handing connections off to a
+        . investigate the feasibility of handing connections off to a
           local apache if they don't look like Tor or if they don't
           portknock or whatever.
       - Get closer to downloading far fewer descriptors
diff --git a/doc/spec/tor-spec.txt b/doc/spec/tor-spec.txt
index b55e088e87..8e7bee3464 100644
--- a/doc/spec/tor-spec.txt
+++ b/doc/spec/tor-spec.txt
@@ -174,7 +174,10 @@ see tor-design.pdf.
    handshake is complete, the initiator renegotiates the handshake, with each
    parties sending a two-certificate chain as in "certificates up-front".
    The initiator's ClientHello MUST include at least once ciphersuite not in
-   the list above.
+   the list above.  The responder SHOULD NOT select any ciphersuite besides
+   those in the list above.
+     [The above "should not" is because some of the ciphers that
+     clients list may be fake.]
 
    In "backwards-compatible renegotiation", the connection initiator's
    ClientHello MUST include at least one ciphersuite other than those listed