[or-cvs] r15653: Added draft for rendezvous protocol version 3. (tor/branches/121-hs-authorization/doc/spec)
kloesing at seul.org
kloesing at seul.org
Fri Jul 4 14:37:50 UTC 2008
Author: kloesing
Date: 2008-07-04 10:37:50 -0400 (Fri, 04 Jul 2008)
New Revision: 15653
Added:
tor/branches/121-hs-authorization/doc/spec/rend-spec-v3draft.txt
Log:
Added draft for rendezvous protocol version 3.
Added: tor/branches/121-hs-authorization/doc/spec/rend-spec-v3draft.txt
===================================================================
--- tor/branches/121-hs-authorization/doc/spec/rend-spec-v3draft.txt (rev 0)
+++ tor/branches/121-hs-authorization/doc/spec/rend-spec-v3draft.txt 2008-07-04 14:37:50 UTC (rev 15653)
@@ -0,0 +1,636 @@
+$Id: rend-spec.txt 15311 2008-06-16 20:31:25Z arma $
+
+ Tor Rendezvous Specification, version 3
+
+0. Overview and preliminaries
+
+ The rendezvous protocol allows Tor users to offer location-hidden
+ services to other Tor users. A service provider Bob can offer a TCP
+ service (say, a webserver) to a client Alice via the onion routing
+ network, without revealing the IP address of that service.
+
+ Bob does this by creating forward circuits to a number of Tor relays,
+ requesting them to act as his contact points and wait for requests to
+ his service. He anonymously advertises a public key for his service,
+ along with a list of contact points. To connect to Bob, Alice fetches
+ Bob's list of contact points, builds a forward circuit to one of them,
+ and sends to it an introduction request that the contact point relays
+ to Bob. If Bob chooses to answer, he replies to his contact point to
+ connect him to Alice which the contact point forwards to Alice. The
+ contact point joins their connections together, and begins relaying
+ cells. Alice's 'BEGIN' cells are received directly by Bob, who passes
+ data to and from the local server implementing Bob's service.
+
+ Below we describe a network-level specification of this service, along
+ with interfaces to make this process transparent to Alice (so long as
+ she is using Tor).
+
+0.1. Version history
+
+ The original design of the rendezvous protocol was based on central
+ directory servers for storing rendezvous descriptors. Instead of
+ contact points as described above, introduction points were used for
+ initiating a client connection and rendezvous points for transferring
+ actual client data. The original design is described in
+ https://www.torproject.org/doc/design-paper/tor-design.html#sec:rendezvous
+ and specified in rend-spec-v1.txt.
+
+ In 0.2.0.10-alpha the storage of hidden service descriptors has been
+ distributed to a changing set of hidden service directories, following
+ proposal 114. The specification for this second rendezvous protocol
+ version is also included in rend-spec-v1.txt in specifically marked
+ paragraphs. Rendezvous protocol versions 1 and 2 can be run in parallel
+ by having separate introduction points and hidden service descriptors.
+
+ This document describes what shall be considered the third rendezvous
+ protocol version. Starting with 0.2.1.x, client authorization has been
+ introduced (proposal 121), the roles of introduction and rendezvous
+ points have been combined to contact points (proposal 142), and
+ distributed storage of descriptors has been further refined (proposal
+ 143). Rendezvous protocol version 3 can be run in parallel to version 1.
+ A hidden service running version 3 can be accessed by clients running
+ version 2 or 3.
+
+0.2. Notation, conventions and prerequisites
+
+ In the specifications below, we use the same notation and terminology
+ as in "tor-spec.txt". The service specified here also requires the
+ existence of an onion routing network as specified in that file.
+
+ H(x) is a SHA1 digest of x.
+ PKSign(SK,x) is a PKCS.1-padded RSA signature of x with SK.
+ PKEncrypt(SK,x) is a PKCS.1-padded RSA encryption of x with SK.
+ Public keys are all RSA, and encoded in ASN.1.
+ All integers are stored in network (big-endian) order.
+ All symmetric encryption uses AES in counter mode, except where
+ otherwise noted.
+
+ In all discussions, "Alice" will refer to the Tor client of a user
+ connecting to a location-hidden service, and "Bob" will refer to the Tor
+ client of a user running a location-hidden service.
+
+0.3. Protocol outline
+
+ 1. Bob requests random Tor relays via Tor to act as contact points.
+ [introduction setup]
+
+ 2. Bob generates keypair X and publishes rendezvous service descriptor
+ to directory service via Tor [advertisement]: "Meet public-key X at
+ contact point A, B, or C." (signed)
+
+ 3. Out of band, Alice receives a z.onion:port address.
+ She requests z.onion:port.
+
+ 4. Alice retrieves Bob's descriptor via Tor. [descriptor lookup]
+
+ 5. Alice connects to contact point via Tor, and tells it about her
+ connection request. (Encrypted to Bob.) [introduction 1]
+
+ 6. The contact point passes this on to Bob via Tor, along the contact
+ circuit. [introduction 2]
+
+ 7. Bob decides whether to connect to Alice, and if so, answers the
+ connection request via Tor. Establishes a shared circuit.
+ [rendezvous 1]
+
+ 8. The contact point relays Bob's confirmation to Alice. [rendezvous 2]
+
+ 9. Alice sends begin cells to Bob. [connection]
+
+0.4. Constants and new cell types
+
+ Relay cell types
+ 32 -- RELAY_COMMAND_ESTABLISH_INTRO
+ 38 -- RELAY_COMMAND_INTRO_ESTABLISHED
+ 41 -- RELAY_COMMAND_INTRODUCE1_VERSIONED
+ 35 -- RELAY_COMMAND_INTRODUCE2
+ 40 -- RELAY_COMMAND_INTRODUCE_ACK
+ 36 -- RELAY_COMMAND_RENDEZVOUS1
+ 37 -- RELAY_COMMAND_RENDEZVOUS2
+
+1. The Protocol
+
+ This section describes a single protocol run of a hidden service Bob
+ establishing and advertising his service in the network and a client
+ Alice accessing that hidden service.
+
+1.1. Bob establishes his contact points.
+
+ Bob randomly picks a few relays that run version 0.2.1.x or higher as
+ contact points. He establishes a new circuit to each contact point.
+ These circuits MUST NOT be used for anything but the hidden service. To
+ establish the contact point, Bob creates a fresh public introduction key
+ pair and an introduction cookie and sends an ESTABLISH_INTRO cell,
+ containing:
+
+ V Format byte: set to 255 [1 octet]
+ V Version byte: set to 2 [1 octet]
+ KLEN Key length [2 octets]
+ PK Public introduction key [KLEN octets]
+ HS Hash of session info [20 octets]
+ SIG Signature of above information [variable]
+
+ To prevent replay attacks, the HS field contains a SHA-1 hash based on
+ the shared secret KH between Bob and the introduction point, as follows:
+ HS = H(KH | "INTRODUCE")
+ That is:
+ HS = H(KH | [49 4E 54 52 4F 44 55 43 45])
+ (KH, as specified in tor-spec.txt, is H(g^xy | [00]) .)
+
+ Upon receiving such a cell, a Tor relay first checks that the signature
+ is correct with the included public key. If so, it checks whether HS is
+ correct given the shared state between Bob and the Tor relay. If either
+ check fails, the Tor relay discards the cell; otherwise, it associates
+ the circuit with the contained introduction key, and dissociates any
+ other circuits currently associated with PK. On success, the relay sends
+ Bob an INTRO_ESTABLISHED cell with an empty payload.
+
+ The hidden service creates a minimum of 3 contact points and increases
+ this number depending on the history of client requests within the last
+ hour. The hidden service also increases this number depending on the
+ frequency of failing contact points in order to defend against attacks
+ on its contact points. When client authorization as described in Section
+ 2 is used, a hidden service also uses the number of authorized clients
+ as first estimate for the required number of contact points.
+
+1.2. Bob generates and uploads service descriptors.
+
+ The first time Bob provides an advertised service, he generates a
+ public/private keypair (stored locally). Bob uses this permanent key to
+ generate a hidden service descriptor:
+
+ "rendezvous-service-descriptor" descriptor-id NL
+
+ [At start, exactly once]
+
+ Indicates the beginning of the descriptor. "descriptor-id" is a
+ periodically changing identifier of 160 bits formatted as 32 base32
+ chars that is calculated by the hidden service and its clients. The
+ "descriptor-id" is calculated by performing the following operation:
+
+ descriptor-id =
+ H(permanent-id | H(time-period | descriptor-cookie | replica))
+
+ "permanent-id" is the permanent identifier of the hidden service,
+ consisting of 80 bits. It can be calculated by computing the hash
+ value of the public hidden service key and truncating after the
+ first 80 bits:
+
+ permanent-id = H(public-key)[:10]
+
+ "H(time-period | descriptor-cookie | replica)" is the (possibly
+ secret) id part that is necessary to verify that the hidden service
+ is the true origin of this descriptor. The descriptor ID can only be
+ created by the hidden service and its clients, but the "signature"
+ below can only be created by the hidden service.
+
+ "time-period" changes periodically as a function of time and of
+ "permanent-id". The current value for "time-period" can be
+ calculated using the following formula:
+
+ time-period = (current-time + permanent-id-byte * 86400 / 256)
+ / 86400
+
+ "current-time" contains the current system time in seconds since
+ 1970-01-01 00:00, e.g. 1188241957. "permanent-id-byte" is the first
+ (unsigned) byte of the permanent identifier (which is in network
+ order), e.g. 143. Adding the product of "permanent-id-byte" and
+ 86400 (seconds per day), divided by 256, prevents "time-period" from
+ changing for all descriptors at the same time of the day. The result
+ of the overall operation is a (network-ordered) 32-bit integer, e.g.
+ 13753 or 0x000035B9 with the example values given above.
+
+ "descriptor-cookie" is an optional secret password of 128 bits that
+ is shared between the hidden service provider and its clients. The
+ descriptor-cookie is used for client authorization as specified in
+ Section 2. If no descriptor-cookie is used, it is left out as input
+ to the hash function.
+
+ "replica" denotes the number of the replica. A service publishes
+ multiple descriptors with different replicas and thereby different
+ descriptor IDs in order to distribute them to different places on
+ the ring.
+
+ "version" version-number NL
+
+ [Exactly once]
+
+ The version number of this descriptor's format. In this case: 2.
+
+ "permanent-key" NL a public key in PEM format
+
+ [Exactly once]
+
+ The public key of the hidden service which is required to verify the
+ "descriptor-id" and the "signature".
+
+ "secret-id-part" secret-id-part NL
+
+ [Exactly once]
+
+ The result of the following operation as explained above, formatted
+ as 32 base32 chars. Using this secret id part, everyone can verify
+ that the signed descriptor is legitimately stored under
+ "descriptor-id".
+
+ secret-id-part = H(time-period | descriptor-cookie | replica)
+
+ "publication-time" YYYY-MM-DD HH:MM:SS NL
+
+ [Exactly once]
+
+ A timestamp when this descriptor has been created.
+
+ "protocol-versions" version-string NL
+
+ [Exactly once]
+
+ A comma-separated list of recognized and permitted version numbers
+ for use in INTRODUCE2 cells; these versions are described in section
+ 1.5 below.
+
+ "introduction-points" NL encrypted-string
+
+ [At most once]
+
+ A list of contact points. If the optional "descriptor-cookie" is
+ used, this string is encrypted with AES in CTR mode with a random
+ initialization vector of 128 bits that is written to the beginning
+ of the encrypted string, and the "descriptor-cookie" as secret key
+ of 128 bits length.
+
+ The string containing the contact point data (either encrypted or
+ not) is encoded in base64, and surrounded with
+ "-----BEGIN MESSAGE-----" and "-----END MESSAGE-----".
+
+ The unencrypted string may begin with:
+
+ "service-authentication" auth-type auth-data NL
+
+ [Any number]
+
+ The service-specific authentication data can be used to perform
+ client authentication. This data is independent of the selected
+ contact point as opposed to "intro-authentication" below. The
+ format of auth-data (base64-encoded or PEM format) depends on
+ auth-type.
+
+ Currently, there are no auth types defined.
+
+ Subsequently, an arbitrary number of contact point entries may
+ follow, each containing the following data:
+
+ "introduction-point" identifier NL
+
+ [At start, exactly once]
+
+ The identifier of this contact point: the base-32 encoded hash
+ of this contact point's identity key.
+
+ "ip-address" ip-address NL
+
+ [Exactly once]
+
+ The IP address of this contact point.
+
+ "onion-port" port NL
+
+ [Exactly once]
+
+ The TCP port on which the contact point is listening for
+ incoming onion requests.
+
+ "onion-key" NL a public key in PEM format
+
+ [Exactly once]
+
+ The public key that can be used to encrypt messages to this
+ contact point.
+
+ "service-key" NL a public key in PEM format
+
+ [Exactly once]
+
+ The public key that can be used to encrypt messages to the
+ hidden service.
+
+ "intro-authentication" auth-type auth-data NL
+
+ [Any number]
+
+ The contact-point-specific authentication data can be used to
+ perform client authentication. This data depends on the selected
+ contact point as opposed to "service-authentication" above. The
+ format of auth-data (base64-encoded or PEM format) depends on
+ auth-type.
+
+ The only defined auth-type so far is "1" with auth-data
+ containing the 128-bit base64-encoded introduction cookie.
+
+ (This ends the fields in the encrypted portion of the descriptor.)
+
+ "signature" NL signature-string
+
+ [At end, exactly once]
+
+ A signature of all fields above created with the private key of the
+ hidden service.
+
+ (This ends the hidden service descriptor format.)
+
+ Bob publishes descriptors to a changing subset of hidden service
+ directories. The client learns about the complete list of hidden service
+ directories by filtering the consensus status document received from the
+ directory authorities for relays containing the "HSDir" flag. A hidden
+ service directory is deemed responsible for all descriptor IDs in the
+ interval from its direct predecessor, exclusive, to its own ID,
+ inclusive. A participant only trusts its own routing list and never
+ learns about routing information from other parties.
+
+ The client opens a stream via Tor to each responsible hidden service
+ directory. (He may re-use old circuits for this.) Over this stream,
+ the client makes an HTTP 'POST' request to a URL
+ "/tor/rendezvous2/publish" relative to the hidden service directory's
+ root, containing as its body Bob's service descriptor.
+
+ Upon receiving a descriptor, the directory server checks the signature,
+ and discards the descriptor if the signature does not match the enclosed
+ public key. Next, the directory server checks the timestamp; if the
+ timestamp is more than 24 hours in the past or more than 1 hour in the
+ future, or the directory server already has a newer descriptor with the
+ same public key, the server discards the descriptor. The directory
+ server also checks whether the claimed descriptor identifier can be
+ created from the descriptor contents. If all tests succeed, the
+ directory node discards any older descriptors with the same descriptor
+ ID and associates the new descriptor with its identifier. Hidden service
+ directories accept publish requests for hidden service descriptors
+ regardless of their own opinion about their responsibility for them.
+ They store descriptors both, to their local memory and to persistent
+ storage. On startup, directories load persistent descriptors to their
+ local memory. The hidden service directory remembers descriptors for at
+ least 3 hours after their maximum validity of 24 hours ends.
+
+ Bob publishes a new descriptor whenever its content changes or a new
+ directory becomes responsible for storing it. At any time, there are 4
+ hidden service directories responsible for keeping replicas of a
+ descriptor with replica indices 1 to 4. For the reason of backwards
+ compatibility, Bob publishes the two descriptors with replica indices 1
+ and 2 also to the successor of the responsible directory in the
+ identifier circle. Descriptors can be found by clients within a given
+ time period of 24 hours, after which they change their ID. If a
+ published descriptor would be valid for less than 60 minutes (= 2 x 30
+ minutes to allow the server to be 30 minutes behind and the client 30
+ minutes ahead), Bob publishes the descriptor under the ID of both, the
+ current and the next publication period.
+
+1.3. Alice receives an onion address.
+
+ When Alice receives a pointer to a location-hidden service, it is as a
+ hostname of the form "z.onion" where z is a base-32 encoding of a
+ 10-octet hash of Bob's service's public key, computed as follows:
+
+ 1. Let H = H(PK).
+ 2. Let H' = the first 80 bits of H, considering each octet from
+ most significant bit to least significant bit.
+ 3. Generate a 16-character encoding of H', using base32 as defined
+ in RFC 3548.
+
+ Only the first 80 of the 160 bits from SHA1 are used here, because there
+ is no need to worry about arbitrary collisions, and because it makes
+ handling the URLs more convenient. Numbers are allowed at the beginning;
+ see RFC 1123.
+
+1.4. Alice retrieves a service descriptor.
+
+ Alice calculates the descriptor ID of a randomly chosen replica and
+ opens a stream via Tor to the responsible hidden service directory. (She
+ may re-use old circuits for this.) Over this stream, Alice makes an HTTP
+ 'GET' request for the document "/tor/rendezvous2/<z>", where <z> is
+ replaced with the encoding of the descriptor ID. The directory replies
+ with a 404 HTTP response if it does not recognize <z>, and otherwise
+ returns Bob's most recently uploaded service descriptor.
+
+ Upon receiving a service descriptor, Alice verifies it with the same
+ process as the hidden service directory uses, described above in section
+ 1.2.
+
+ Alice caches the descriptor locally for a maximum time of 15 minutes.
+ (Caching may make her partitionable, but she fetched it anonymously,
+ and we can't very well *not* cache it.)
+
+ If a request is unsuccessful, Alice retries fetching the descriptor
+ using the remaining descriptor IDs from the responsible hidden service
+ directories in random order. She keeps a local 5-minutes long history of
+ fetch attempts to avoid requesting the same descriptor twice from a
+ directory within this time. Alice relies on Bob to care about a
+ potential clock skew between the two by possibly storing two sets of
+ descriptors (see end of section 1.3).
+
+ Hidden service directory nodes process fetch requests for hidden service
+ descriptors by looking them up in their local memory. They do not need
+ to determine if they are responsible for a descriptor ID, because it
+ does no harm if they deliver a descriptor for which they are not
+ responsible (any more).
+
+1.5. Introduction: from Alice to Contact Point
+
+ Alice builds a circuit to one of Bob's chosen contact points, and sends
+ it an INTRODUCE1_VERSIONED cell containing:
+
+ Cleartext
+ V Version byte: set to 2 [1 octet]
+ PK_ID Introduction key identifier [20 octets]
+ RC Rendezvous cookie [20 octets]
+ Encrypted to introduction key:
+ VER Version byte: set to 3. [1 octet]
+ AUTHT The auth type that is used [1 octet]
+ AUTHL Length of auth data [2 octets]
+ AUTHD Auth data [variable]
+ RC Rendezvous cookie [20 octets]
+ g^x Diffie-Hellman data, part 1 [128 octets]
+
+ PK_ID is the hash of the introduction key. The introduction cookie is
+ included as auth data of length 20 octets for auth type "1".
+
+1.6. Introduction: From the Contact Point to Bob
+
+ If the contact point recognizes PK_ID as the hash of a public key which
+ has established a circuit for introductions as in 1.1 above, it stores
+ the rendezvous cookie and sends the body of the cell in a new INTRODUCE2
+ cell down the corresponding circuit. (If the PK_ID is unrecognized, the
+ INTRODUCE1_VERSIONED cell is discarded.)
+
+ After sending the INTRODUCE2 cell, the contact point replies to Alice
+ with an empty INTRODUCE_ACK cell. If no INTRODUCE2 cell can be sent,
+ the contact point replies to Alice with a 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 failure.)
+
+1.7. Rendezvous: From Bob to the Contact Point
+
+ When Bob receives the INTRODUCE2 cell, he decrypts it with the
+ corresponding private introduction key, and extracts the introduction
+ cookie, the rendezvous cookie, and the value of g^x chosen by Alice.
+ If the introduction cookie is valid, Bob sends a RENDEZVOUS1 cell along
+ the contact circuit, containing:
+
+ RC Rendezvous cookie [20 octets]
+ g^y Diffie-Hellman [128 octets]
+ KH Handshake digest [20 octets]
+
+1.8. Rendezvous: From the Contact Point to Alice
+
+ When a contact point receives a RENDEZVOUS1 cell, it checks whether it
+ recognizes the contained rendezvous cookie. If so, it relays the
+ rest of the cell down the corresponding circuit in a RENDEZVOUS2 cell,
+ containing:
+
+ g^y Diffie-Hellman [128 octets]
+ KH Handshake digest [20 octets]
+
+ (If the contact point does not recognize the RC, it discards the cell.)
+
+ When Alice receives a RENDEZVOUS2 cell on a circuit which has sent an
+ INTRODUCE1_VERSIONED cell but which has not yet received a reply, it
+ uses g^y and H(g^xy) to complete the handshake as in the Tor circuit
+ extend process: they establish a 60-octet string as
+ K = SHA1(g^xy | [00]) | SHA1(g^xy | [01]) | SHA1(g^xy | [02])
+ and generate
+ KH = K[0..15]
+ Kf = K[16..31]
+ Kb = K[32..47]
+
+ Subsequently, the rendezvous point passes relay cells, unchanged, from
+ each of the two circuits to the other. When Alice sends RELAY cells
+ along the circuit, she first encrypts them with the Kf, then with all of
+ the keys for the relays in Alice's side of the circuit; and when Alice
+ receives RELAY cells from the circuit, she decrypts them with the keys
+ for the relays in Alice's side of the circuit, then decrypts them with
+ Kb. Bob does the same, with Kf and Kb interchanged.
+
+1.9. Creating streams
+
+ To open TCP connections to Bob's location-hidden service, Alice sends
+ a RELAY_BEGIN cell along the established circuit, using the special
+ address "", and a chosen port. Bob chooses a destination IP and port,
+ based on the configuration of the service connected to the circuit, and
+ opens a TCP stream. From then on, Bob treats the stream as an ordinary
+ exit connection, except he doesn't include addr in the connected cell or
+ the end cell.
+
+ Alice MAY send multiple RELAY_BEGIN cells along the circuit, to open
+ multiple streams to Bob. Alice SHOULD NOT send RELAY_BEGIN cells for any
+ other address along her circuit to Bob; if she does, Bob MUST reject
+ them.
+
+2. Authentication and authorization.
+
+ The rendezvous protocol as specified above permits access to a hidden
+ service to all anonymous clients that learn the service's onion address.
+ This section describes the necessary modifications to restrict access
+ to a hidden service to selected clients only and hide existence from
+ everybody else.
+
+2.1. Client-specific service descriptors.
+
+ Bob creates a pair of one asymmetric ("client-key") and one symmetric
+ key ("descriptor-cookie") for each authorized client. In step 1.2, Bob
+ uses the client key instead of his permanent key to generate a separate
+ service descriptor for each client. Further, Bob includes the descriptor
+ cookie in the generation process of the descriptor ID and to encrypt the
+ list of contact points. Bob does not include an introduction cookie in
+ the descriptor.
+
+2.2. Client-specific authorization data.
+
+ The onion address for a hidden service with restricted access is
+ different for each client; it is derived from the client key in the same
+ way as an onion address for an unrestricted service is derived from a
+ service's permanent key; see Section 1.3. In addition to the onion
+ address, Bob tells Alice the secret descriptor cookie.
+
+2.3. Retrieve service descriptor.
+
+ Alice calculates the descriptor ID in the same way as Bob did before;
+ see 1.4. This includes using the client key and descriptor cookie.
+
+2.4. Client authorization at hidden service.
+
+ When sending an introduction request, Alice includes the descriptor
+ cookie instead of the introduction cookie in her INTRODUCE2 cell that
+ she sends to Bob. She uses auth-type "2" for this.
+
+2.5. Access control.
+
+ Bob compares authorization data of incoming INTRODUCE2 cells with
+ locally stored values of permitted clients. If a descriptor cookie is
+ accepted, Bob replies to the contact point to establish a connection
+ with the requesting client. In all other cases, Bob drops the cell.
+
+3. Hidden service directory consensus.
+
+ Alice and Bob need to agree on the same or similar set of hidden service
+ directories, so that Alice finds the service descriptors that Bob
+ stores.
+
+3.1. Configuring as hidden service directory
+
+ Every relay that has its directory port open can decide whether it wants
+ to store and serve hidden service descriptors. An onion router which is
+ configured as such includes the "hidden-service-dir" flag in its router
+ descriptors that it sends to directory authorities.
+
+3.2. Authorities voting on hidden service directories
+
+ The directory authorities include a flag "HSDir" in their votes for the
+ version 3 directory protocol (see dir-spec.txt) for relays that decided
+ to provide storage for hidden service descriptors, that have been
+ running for at least 24 hours, and that are not know bad hidden service
+ directories (see 3.3 below).
+
+ In a network status consensus a relay is assigned the "HSDir" flag, if
+ the majority of votes contains a HSDir flag and no more than one third
+ of votes contains a BadHSDir flag.
+
+3.3. Reporting bad hidden service directories
+
+ Bob tries to download his descriptor replicas every hour at random times
+ from the responsible hidden service directories. If a directory node
+ replies with 404 (Not found), the hidden service reports the supposedly
+ bad directory node to a random selection of half of the directory
+ authorities (with version numbers equal to or higher than 0.2.1.x). Bob
+ posts this complaint message using HTTP 'POST' to a URL
+ "/tor/rendezvous/complain" with the following message format:
+
+ "hidden-service-directory-complaint" identifier NL
+
+ [At start, exactly once]
+
+ The identifier of the hidden service directory node to be
+ investigated.
+
+ "rendezvous-service-descriptor" descriptor NL
+
+ [At end, Excatly once]
+
+ The hidden service descriptor that the supposedly bad directory node
+ does not serve.
+
+ The directory authority checks if the descriptor is valid and the hidden
+ service directory responsible for storing it based on the most current
+ consensus. It waits for a random time of up to 30 minutes before posting
+ the descriptor to the hidden service directory. If the publication is
+ acknowledged, the directory authority waits another random time of up to
+ 30 minutes before attempting to request the descriptor that it has
+ posted. If the directory node replies with 404 (Not found), it is
+ blacklisted for being a hidden service directory node for the next 48
+ hours. A blacklisted hidden service directory is assigned the "BadHSDir"
+ flag in the vote that a directory authority creates.
+
+ In order to prevent an attacker from setting up new nodes as replacement
+ for blacklisted directory nodes, all directory nodes in the same /24
+ subnet are blacklisted, too. Furthermore, if two or more directory nodes
+ are blacklisted in the same /16 subnet concurrently, all other directory
+ nodes in that /16 subnet are blacklisted, too. Blacklisting holds for at
+ most 48 hours.
+
More information about the tor-commits
mailing list