mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
7afe2adbaf
svn:r474
201 lines
9.6 KiB
Plaintext
201 lines
9.6 KiB
Plaintext
How to make rendezvous points work
|
|
|
|
0. Overview
|
|
|
|
Rendezvous points are an implementation of location-hidden services
|
|
(server anonymity) in the onion routing network. Location-hidden
|
|
services means Bob can offer a tcp service (say, a webserver) via the
|
|
onion routing network, without revealing the IP of that service.
|
|
|
|
The basic idea is to provide censorship resistance for Bob by allowing
|
|
him to advertise a variety of onion routers as his public location
|
|
(nodes known as his Introduction Points, see Section 1). Alice,
|
|
the client, chooses a node known as a Meeting Point (see Section
|
|
2). This extra level of indirection is needed so Bob doesn't serve
|
|
files directly from his public locations (so these nodes don't open
|
|
themselves up to abuse, eg from serving Nazi propaganda in France). The
|
|
extra level of indirection also allows Bob to choose which requests
|
|
to respond to, and which to ignore.
|
|
|
|
We provide the necessary glue code so that Alice can view webpages
|
|
on a location-hidden webserver, and Bob can run a location-hidden
|
|
server, with minimal invasive changes (see Section 3). Both Alice
|
|
and Bob must run local onion proxies (OPs) -- software that knows
|
|
how to talk to the onion routing network.
|
|
|
|
The big picture follows. We direct the reader to the rest of the
|
|
document for more details and explanation.
|
|
|
|
1) Bob chooses some Introduction Points, and advertises them on a
|
|
Distributed Hash Table (DHT).
|
|
2) Bob establishes onion routing connections to each of his
|
|
Introduction Points, and waits.
|
|
3) Alice learns about Bob's service out of band (perhaps Bob gave her
|
|
a pointer, or she found it on a website). She looks up the details
|
|
of Bob's service from the DHT.
|
|
4) Alice chooses and establishes a Meeting Point for this transaction.
|
|
5) Alice goes to one of Bob's Introduction Points, and gives it a blob
|
|
(encrypted for Bob) which tells him about herself and the Meeting
|
|
Point she chose. The Introduction Point sends the blob to Bob.
|
|
6) Bob chooses whether to ignore the blob, or to onion route to MP.
|
|
Let's assume the latter.
|
|
7) MP plugs together Alice and Bob. Note that MP doesn't know (or care)
|
|
who Alice is, or who Bob is; and it can't read anything they
|
|
transmit either, because they share a session key.
|
|
8) Alice sends a 'begin' cell along the circuit. It makes its way
|
|
to Bob's onion proxy. Bob's onion proxy connects to Bob's webserver.
|
|
9) Data goes back and forth as usual.
|
|
|
|
1. Introduction service
|
|
|
|
Bob wants to learn about client requests for communication, but
|
|
wants to avoid responding unnecessarily to unauthorized clients.
|
|
Bob's proxy opens a circuit, and tells some onion router on that
|
|
circuit to expect incoming connections, and notify Bob of them.
|
|
|
|
When establishing such an introduction point, Bob provides the onion
|
|
router with a public "introduction" key. The hash of this public
|
|
key identifies a unique Bob, and (since Bob is required to sign his
|
|
messages) prevents anybody else from usurping Bob's introduction
|
|
point in the future. Additionally, Bob can use the same public key
|
|
to establish an introduction point on another onion router (OR),
|
|
and Alice can still be confident that Bob is the same server.
|
|
|
|
(The set-up-an-introduction-point command should come via a
|
|
RELAY_BIND_INTRODUCTION cell. This cell creates a new stream on the
|
|
circuit from Bob to the introduction point.)
|
|
|
|
ORs that support introduction run an introduction service on a
|
|
separate port. When Alice wants to notify Bob of a meeting point,
|
|
she connects (directly or via Tor) to the introduction port, and
|
|
sends the following:
|
|
|
|
MEETING REQUEST
|
|
RSA-OAEP encrypted with server's public key:
|
|
[20 bytes] Hash of Bob's public key (identifies which Bob to notify)
|
|
[ 0 bytes] Initial authentication [optional]
|
|
RSA encrypted with Bob's public key:
|
|
[16 bytes] Symmetric key for encrypting blob past RSA
|
|
[ 6 bytes] Meeting point (IP/port)
|
|
[ 8 bytes] Meeting cookie
|
|
[ 0 bytes] End-to-end authentication [optional]
|
|
[98 bytes] g^x part 1 (inside the RSA)
|
|
[30 bytes] g^x part 2 (symmetrically encrypted)
|
|
|
|
The meeting point and meeting cookie allow Bob to contact Alice and
|
|
prove his identity; the end-to-end authentication enables Bob to
|
|
decide whether to talk to Alice; the initial authentication enables
|
|
the meeting point to pre-screen introduction requests before sending
|
|
them to Bob. (See Section 2 for a discussion of meeting points;
|
|
see Section 1.1 for an example authentication mechanism.)
|
|
|
|
The authentication steps are the appropriate places for the
|
|
introduction server or Bob to do replay prevention, if desired.
|
|
|
|
When the introduction point receives a valid meeting request, it
|
|
sends the portion intended for Bob along the stream
|
|
created by Bob's RELAY_BIND_INTRODUCTION. Bob then, at his
|
|
discretion, connects to Alice's meeting point.
|
|
|
|
1.1. An example authentication scheme for introduction services
|
|
|
|
Bob makes two short-term secrets SB and SN, and tells the
|
|
introduction point about SN. Bob gives Alice a cookie consisting
|
|
of A,B,C such that H(A|SB)=B and H(A|SN)=C. Alice's initial
|
|
authentication is <A,C>; Alice's end-to-end authentication is <A,B>.
|
|
|
|
[Maybe] Bob keeps a replay cache of A values, and doesn't allow any
|
|
value to be used twice. Over time, Bob rotates SB and SN.
|
|
|
|
[Maybe] Each 'A' has an expiration time built in to it.
|
|
|
|
In reality, we'll want to pick a scheme that (a) wasn't invented from
|
|
scratch in an evening, and (b) doesn't require Alice to remember this
|
|
many bits (see section 3.2).
|
|
|
|
2. Meeting points
|
|
|
|
For Bob to actually reply to Alice, Alice first establishes a
|
|
circuit to an onion router R, and sends a RELAY_BIND_MEETING cell
|
|
to that onion router. The RELAY_BIND_MEETING cell contains a
|
|
'Meeting cookie' (MC) that Bob can use to authenticate to R. R
|
|
remembers the cookie and associates it with Alice.
|
|
|
|
Later, Bob also routes to R and sends R a RELAY_JOIN_MEETING cell with
|
|
the meeting cookie MC. After this point, R routes all traffic from
|
|
Bob's circuit or Alice's circuit as if the two circuits were joined:
|
|
any RELAY cells that are not for a recognized topic are passed down
|
|
Alice or Bob's circuit. Bob's first cell to Alice contains g^y.
|
|
|
|
To prevent R from reading their traffic, Alice and Bob derive two
|
|
end-to-end keys from g^{xy}, and they each treat R as just another
|
|
hop on the circuit. (These keys are used in addition to the series
|
|
of encryption keys already in use on Alice and Bob's circuits.)
|
|
|
|
Bob's OP accepts RELAY_BEGIN, RELAY_DATA, RELAY_END, and
|
|
RELAY_SENDME cells from Alice. Alice's OP accepts RELAY_DATA,
|
|
RELAY_END, and RELAY_SENDME cells from Bob. All RELAY_BEGIN cells
|
|
to Bob must have target IP and port of zero; Bob's OP will redirect
|
|
them to the actual target IP and port of Bob's server.
|
|
|
|
Alice and Bob's OPs disallow CREATE or RELAY_EXTEND cells as usual.
|
|
|
|
3. Application interface
|
|
|
|
3.1. Application interface: server side
|
|
|
|
Bob has a service that he wants to offer to the world but keep its
|
|
location hidden. He configures his local OP to know about this
|
|
service, including the following data:
|
|
|
|
Local IP and port of the service
|
|
Strategy for choosing introduction points
|
|
(for now, just randomly pick among the ORs offering it)
|
|
Strategy for user authentication
|
|
(for now, just accept all users)
|
|
Public (RSA) key (one for each service Bob offers)
|
|
|
|
Bob chooses a set of N Introduction servers on which to advertise
|
|
his service.
|
|
|
|
We assume the existence of a robust decentralized efficient lookup
|
|
system (call it "DHT" for distributed hash table -- note that the
|
|
onion routers can run nodes). Bob publishes
|
|
* Bob's Public Key for that service
|
|
* Expiration date ("don't use after")
|
|
* Introduction server 0 ... Introduction server N
|
|
(All signed by Bob's Public Key)
|
|
into DHT, indexed by the hash of Bob's Public Key. Bob should
|
|
periodically republish his introduction information with a new
|
|
expiration date (and possibly with new/different introduction servers
|
|
if he wants), so Alice can trust that DHT is giving her an up-to-date
|
|
version. The Chord CFS paper describes a sample DHT that allows
|
|
authenticated updating.
|
|
|
|
3.2. Application interface: client side
|
|
|
|
We require that the client interface remain a SOCKS proxy, and we
|
|
require that Alice shouldn't have to modify her applications. Thus
|
|
we encode all of the necessary information into the hostname (more
|
|
correctly, fqdn) that Alice uses, eg when clicking on a url in her
|
|
browser.
|
|
|
|
To establish a connection to Bob, Alice needs to know an Introduction
|
|
point, Bob's PK, and some authentication cookie. Because encoding this
|
|
information into the hostname will be too long for a typical hostname,
|
|
we instead use a layer of indirection. We encode a hash of Bob's PK
|
|
(10 bytes is sufficient since we're not worrying about collisions),
|
|
and also the authentication token (empty for now). Location-hidden
|
|
services use the special top level domain called '.onion': thus
|
|
hostnames take the form x.y.onion where x is the hash of PK, and y
|
|
is the authentication cookie. If no cookie is required, the hostname
|
|
can simply be of the form x.onion. Assuming only case insensitive
|
|
alphanumeric and hyphen, we get a bit more than 6 bits encoded
|
|
per character, meaning the x part of the hostname will be about
|
|
13 characters.
|
|
|
|
Alice's onion proxy examines hostnames and recognizes when they're
|
|
destined for a hidden server. If so, it decodes the PK and performs
|
|
the steps in Section 0 above.
|
|
|