mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-30 15:43:32 +01:00
Update tor-spec with new EXTEND format and info about certificate chains
svn:r1995
This commit is contained in:
parent
541add90a1
commit
53b21c65f7
9
doc/TODO
9
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
|
||||||
|
@ -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
|
An OR always sends two-certificate chain, consisting of a self-signed
|
||||||
is the server's nickname, and whose public key is in the server
|
certificate containing the OR's identity key, and of a second certificate
|
||||||
directory.
|
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
|
All parties receiving certificates must confirm that the identity key is
|
||||||
key is as it appears in the server directory, and close the
|
as expected. (When initiating a connection, the expected identity key is
|
||||||
connection if it is not.
|
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:
|
||||||
|
Loading…
Reference in New Issue
Block a user