nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-27 22:03:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
svn:r1995
This commit is contained in:
Nick Mathewson 2004-07-01 01:34:02 +00:00
parent 541add90a1
commit 53b21c65f7
2 changed files with 29 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
doc/TODO
View File

@ -51,9 +51,13 @@ NICK pre1:
pre2:
- 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
hidserv descs.
hidserv descs. [XXXX This isn't enough.]
- figure out what to do about ip:port:differentkey
ARMA - ORs connect on demand. attach circuits to new connections, keep
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
hash-base64'ed.
pre3:
- users can set their bandwidth, or we auto-detect it:
- advertised bandwidth defaults to 10KB

30
doc/tor-spec.txt
View File

@ -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.
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
different OPs, and compromise their anonymity.
- Alternatively, directories should include IPs.
@ -68,13 +68,19 @@ TODO: (very soon)
support any suite without ephemeral keys, symmetric keys of at
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
(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:
Address [4 bytes]
Port [2 bytes]
Public key hash [20 bytes]
Onion skin [186 bytes]
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
EXTENDED cell, contains: