浏览代码

Update tor-spec with new EXTEND format and info about certificate chains

svn:r1995
Nick Mathewson 21 年之前
父节点
当前提交
53b21c65f7
共有 2 个文件被更改,包括 29 次插入10 次删除
  1. 7 2
      doc/TODO
  2. 22 8
      doc/tor-spec.txt

+ 7 - 2
doc/TODO

@@ -51,9 +51,13 @@ NICK  pre1:
 
 
       pre2:
       pre2:
         - refer to things by key:
         - refer to things by key:
-          - extend cells need ip:port:identitykeyhash.
+          o extend cells need ip:port:identitykeyhash.
+	  . Lookup routers and connections by key digest; accept hex
+            key digest in place of nicknames.
+          - Audit all uses of lookup-by-hostname and lookup-by-addr-port
+            to search by digest when appropriate.
           - also use this in intro points and rendezvous points, and
           - also use this in intro points and rendezvous points, and
-            hidserv descs.
+            hidserv descs.  [XXXX This isn't enough.]
           - figure out what to do about ip:port:differentkey
           - figure out what to do about ip:port:differentkey
 ARMA    - ORs connect on demand. attach circuits to new connections, keep
 ARMA    - ORs connect on demand. attach circuits to new connections, keep
           create cells around somewhere, send destroy if fail.
           create cells around somewhere, send destroy if fail.
@@ -61,6 +65,7 @@ ARMA    - ORs connect on demand. attach circuits to new connections, keep
         - running-routers list refers to nickname if verified, else
         - running-routers list refers to nickname if verified, else
           hash-base64'ed.
           hash-base64'ed.
 
 
+
       pre3:
       pre3:
         - users can set their bandwidth, or we auto-detect it:
         - users can set their bandwidth, or we auto-detect it:
           - advertised bandwidth defaults to 10KB
           - advertised bandwidth defaults to 10KB

+ 22 - 8
doc/tor-spec.txt

@@ -11,7 +11,7 @@ This is not a design document; most design criteria are not examined.  For
 more information on why Tor acts as it does, see tor-design.pdf.
 more information on why Tor acts as it does, see tor-design.pdf.
 
 
 TODO: (very soon)
 TODO: (very soon)
-      - EXTEND cells should have hostnames or nicknames, so that OPs never
+      X EXTEND cells should have hostnames or nicknames, so that OPs never
         resolve OR hostnames.  Else DNS servers can give different answers to
         resolve OR hostnames.  Else DNS servers can give different answers to
         different OPs, and compromise their anonymity.
         different OPs, and compromise their anonymity.
          - Alternatively, directories should include IPs.
          - Alternatively, directories should include IPs.
@@ -68,13 +68,19 @@ TODO: (very soon)
    support any suite without ephemeral keys, symmetric keys of at
    support any suite without ephemeral keys, symmetric keys of at
    least 128 bits, and digests of at least 160 bits.
    least 128 bits, and digests of at least 160 bits.
 
 
-   An OR always sends a self-signed X.509 certificate whose commonName
-   is the server's nickname, and whose public key is in the server
-   directory.
+   An OR always sends two-certificate chain, consisting of a self-signed
+   certificate containing the OR's identity key, and of a second certificate
+   using a short-term connection key.  The commonName of the second
+   certificate is the OR's nickname, and the commonName of the first
+   certificate is the OR's nickname, followed by a space and the string
+   "<identity>".
 
 
-   All parties receiving certificates must confirm that the public
-   key is as it appears in the server directory, and close the
-   connection if it is not.
+   All parties receiving certificates must confirm that the identity key is
+   as expected.  (When initiating a connection, the expected identity key is
+   the one given in the directory; when creating a connection because of an
+   EXTEND cell, the expected identity key is the one given in the cell.)  If
+   the key is not as expected, the party must close the connection if it is
+   not.
 
 
    Once a TLS connection is established, the two sides send cells
    Once a TLS connection is established, the two sides send cells
    (specified below) to one another.  Cells are sent serially.  All
    (specified below) to one another.  Cells are sent serially.  All
@@ -169,10 +175,18 @@ TODO: (very soon)
    The relay payload for an EXTEND relay cell consists of:
    The relay payload for an EXTEND relay cell consists of:
          Address                       [4 bytes]
          Address                       [4 bytes]
          Port                          [2 bytes]
          Port                          [2 bytes]
+         Public key hash               [20 bytes]
          Onion skin                    [186 bytes]
          Onion skin                    [186 bytes]
 
 
    The port and address field denote the IPV4 address and port of the
    The port and address field denote the IPV4 address and port of the
-   next onion router in the circuit.
+   next onion router in the circuit; the public key hash is the SHA1 hash of
+   the ASN1 encoding of the next onion router's identity key.
+
+   [XXXX Before 0.0.8, EXTEND cells did not include the public key hash.
+   Servers running 0.0.8 distinguish the old-style cells based on the length
+   of payloads.  Clients running 0.0.8 check for servers version 0.0.7 or
+   later, and send them the old-style EXTEND cells.  In a future release,
+   old-style EXTEND cells will not be supported.]
 
 
    The payload for a CREATED cell, or the relay payload for an
    The payload for a CREATED cell, or the relay payload for an
    EXTENDED cell, contains:
    EXTENDED cell, contains: