mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-20 10:12:15 +01:00
Code Issues Projects Releases Wiki Activity

Merge commit 'karsten/rendspec-koryk'

Browse Source
This commit is contained in:
Nick Mathewson 2010-08-25 16:44:37 -04:00
commit 2804c6b7ff
1 changed files with 30 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
doc/spec/rend-spec.txt
View File

@ -150,7 +150,7 @@
The first time the OP provides an advertised service, it generates The first time the OP provides an advertised service, it generates
a public/private keypair (stored locally). a public/private keypair (stored locally).
The OP choses a small number of Tor servers as introduction points. The OP chooses a small number of Tor servers as introduction points.
The OP establishes a new introduction circuit to each introduction The OP establishes a new introduction circuit to each introduction
point. These circuits MUST NOT be used for anything but hidden service point. These circuits MUST NOT be used for anything but hidden service
introduction. To establish the introduction, Bob sends a introduction. To establish the introduction, Bob sends a
@ -238,6 +238,9 @@
permanent-id = H(public-key)[:10] permanent-id = H(public-key)[:10]
Note: If Bob's OP has "stealth" authorization enabled (see Section 2.2),
it uses the client key in place of the public hidden service key.
"H(time-period | descriptor-cookie | replica)" is the (possibly "H(time-period | descriptor-cookie | replica)" is the (possibly
secret) id part that is necessary to verify that the hidden service is secret) id part that is necessary to verify that the hidden service is
the true originator of this descriptor and that is therefore contained the true originator of this descriptor and that is therefore contained
@ -668,8 +671,8 @@
circuit. (If the PK_ID is unrecognized, the RELAY_COMMAND_INTRODUCE1 cell is circuit. (If the PK_ID is unrecognized, the RELAY_COMMAND_INTRODUCE1 cell is
discarded.) discarded.)
After sending the RELAY_COMMAND_INTRODUCE2 cell, the OR replies to Alice After sending the RELAY_COMMAND_INTRODUCE2 cell to Bob, the OR replies to
with an empty RELAY_COMMAND_INTRODUCE_ACK cell. If no Alice with an empty RELAY_COMMAND_INTRODUCE_ACK cell. If no
RELAY_COMMAND_INTRODUCE2 cell can be sent, the OR replies to Alice with a RELAY_COMMAND_INTRODUCE2 cell can be sent, the OR replies to Alice with a
non-empty cell to indicate an error. (The semantics of the cell body may be non-empty cell to indicate an error. (The semantics of the cell body may be
determined later; the current implementation sends a single '1' byte on determined later; the current implementation sends a single '1' byte on
@ -759,11 +762,11 @@
2.1. Service with large-scale client authorization 2.1. Service with large-scale client authorization
The first client authorization protocol aims at performing access control The first client authorization protocol aims at performing access control
while consuming as few additional resources as possible. A service while consuming as few additional resources as possible. This is the "basic"
provider should be able to permit access to a large number of clients authorization protocol. A service provider should be able to permit access
while denying access for everyone else. However, the price for to a large number of clients while denying access for everyone else.
scalability is that the service won't be able to hide its activity from However, the price for scalability is that the service won't be able to hide
unauthorized or formerly authorized clients. its activity from unauthorized or formerly authorized clients.
The main idea of this protocol is to encrypt the introduction-point part The main idea of this protocol is to encrypt the introduction-point part
in hidden service descriptors to authorized clients using symmetric keys. in hidden service descriptors to authorized clients using symmetric keys.
@ -822,19 +825,19 @@
2.2. Authorization for limited number of clients 2.2. Authorization for limited number of clients
A second, more sophisticated client authorization protocol goes the extra A second, more sophisticated client authorization protocol goes the extra
mile of hiding service activity from unauthorized clients. With all else mile of hiding service activity from unauthorized clients. This is the
being equal to the preceding authorization protocol, the second protocol "stealth" authorization protocol. With all else being equal to the preceding
publishes hidden service descriptors for each user separately and gets authorization protocol, the second protocol publishes hidden service
along with encrypting the introduction-point part of descriptors to a descriptors for each user separately and gets along with encrypting the
single client. This allows the service to stop publishing descriptors for introduction-point part of descriptors to a single client. This allows the
removed clients. As long as a removed client cannot link descriptors service to stop publishing descriptors for removed clients. As long as a
issued for other clients to the service, it cannot derive service removed client cannot link descriptors issued for other clients to the
activity any more. The downside of this approach is limited scalability. service, it cannot derive service activity any more. The downside of this
Even though the distributed storage of descriptors (cf. proposal 114) approach is limited scalability. Even though the distributed storage of
tackles the problem of limited scalability to a certain extent, this descriptors (cf. proposal 114) tackles the problem of limited scalability to
protocol should not be used for services with more than 16 clients. (In a certain extent, this protocol should not be used for services with more
fact, Tor should refuse to advertise services for more than this number than 16 clients. (In fact, Tor should refuse to advertise services for more
of clients.) than this number of clients.)
A hidden service generates an asymmetric "client key" and a symmetric A hidden service generates an asymmetric "client key" and a symmetric
"descriptor cookie" for each client. The client key is used as "descriptor cookie" for each client. The client key is used as
@ -882,14 +885,16 @@
A hidden service that is meant to perform client authorization adds a A hidden service that is meant to perform client authorization adds a
new option HiddenServiceAuthorizeClient to its hidden service new option HiddenServiceAuthorizeClient to its hidden service
configuration. This option contains the authorization type which is configuration. This option contains the authorization type which is
either "1" for the protocol described in 2.1 or "2" for the protocol in either "basic" for the protocol described in 2.1 or "stealth" for the
2.2 and a comma-separated list of human-readable client names, so that protocol in 2.2 and a comma-separated list of human-readable client
Tor can create authorization data for these clients: names, so that Tor can create authorization data for these clients:
HiddenServiceAuthorizeClient auth-type client-name,client-name,... HiddenServiceAuthorizeClient auth-type client-name,client-name,...
If this option is configured, HiddenServiceVersion is automatically If this option is configured, HiddenServiceVersion is automatically
reconfigured to contain only version numbers of 2 or higher. reconfigured to contain only version numbers of 2 or higher. There is
a maximum of 512 client names for basic auth and a maximum of 16 for
stealth auth.
Tor stores all generated authorization data for the authorization Tor stores all generated authorization data for the authorization
protocols described in Sections 2.1 and 2.2 in a new file using the protocols described in Sections 2.1 and 2.2 in a new file using the