1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
How to make rendezvous points work
1-11Jun2003
0. Overview
Rendezvous points are an implementation of server anonymity /
location-hidden servers in the onion routing network. There are
three components needed for rendezvous points:
A) A means for the client ("Alice") to tell a server ("Bob") where
to contact her in order to establish a connection. (Introduction)
B) A means for Bob to contact Alice to actually establish the
connection, and for them to communicate later. (Meeting)
C) 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. (Application)
We'll tackle these in order. In all cases, we'll assume that both
Alice and Bob run local OPs.
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 uniquely identifies Bob, and 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 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 3 for a discussion of meeting points;
see 2.1 for a proposed 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.
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"). Bob publishes
* Bob's Public Key for that service
* Timestamp
* 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
timestamp (and possibly with new/different introduction servers if
he wants), so Alice can trust that DHT is giving her an up-to-date
version.
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 that
Alice uses (eg when clicking on a url in her browser, etc).
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). Thus at a bit more
than 6 bits encoded per character (assuming only alphanumeric and
hyphen), we transform the hostname "moria.mit.edu" into the hostname
"moria.mit.edu.onion5gfmjsda-ckd5" (adding 13 characters plus the
separator).
Alice's onion proxy examines hostnames and recognizes when they're
destined for a hidden server. If so, it decodes the PK, looks it up in
the DHT, chooses and connects to a meeting place, chooses and connects
to one of Bob's introduction servers, and then waits to hear from Bob.
|
