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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
|
```
Filename: 196-transport-control-ports.txt
Title: Extended ORPort and TransportControlPort
Author: George Kadianakis, Nick Mathewson
Created: 14 Mar 2012
Status: Closed
Implemented-In: 0.2.5.2-alpha
1. Overview
Proposal 180 defined Tor pluggable transports, a way to decouple
protocol-level obfuscation from the core Tor protocol in order to
better resist client-bridge censorship. This is achieved by
introducing pluggable transport proxies, programs that obfuscate Tor
traffic to resist DPI detection.
Proposal 180 defined a way for pluggable transport proxies to
communicate with local Tor clients and bridges, so as to exchange
traffic. This document extends this communication protocol, so that
pluggable transport proxies can exchange arbitrary operational
information and metadata with Tor clients and bridges.
2. Motivation
The communication protocol specified in Proposal 180 gives a way
for transport proxies to announce the IP address of their clients
to tor. Still, modern pluggable transports might have more (?)
needs than this. For example:
1. Tor might want to inform pluggable transport proxies on how to
rate-limit incoming or outgoing connections.
2. Server pluggable transport proxies might want to pass client
information to an anti-active-probing system controlled by tor.
3. Tor might want to temporarily stop a transport proxy from
obfuscating traffic.
To satisfy the above use cases, there must be real-time
communication between the tor process and the pluggable transport
proxy. To achieve this, this proposal refactors the Extended ORPort
protocol specified in Proposal 180, and introduces a new port,
TransportControlPort, whose sole role is the exchange of control
information between transport proxies and tor.
Specifically, transports proxies deliver each connection to the
"Extended ORPort", where they provide metadata and agree on an
identifier for each tunneled connection. Once this handshake
occurs, the OR protocol proceeds unchanged.
Additionally, each transport maintains a single connection to Tor's
"TransportControlPort", where it receives instructions from Tor
about rate-limiting on individual connections.
3. The new port protocols
3.1. The new extended ORPort protocol
3.1.1. Protocol
The extended server port protocol is as follows:
COMMAND [2 bytes, big-endian]
BODYLEN [2 bytes, big-endian]
BODY [BODYLEN bytes]
Commands sent from the transport proxy to the bridge are:
[0x0000] DONE: There is no more information to give. The next
bytes sent by the transport will be those tunneled over it.
(body ignored)
[0x0001] USERADDR: an address:port string that represents the
client's address.
[0x0002] TRANSPORT: a string of the name of the pluggable
transport currently in effect on the connection.
Replies sent from tor to the proxy are:
[0x1000] OKAY: Send the user's traffic. (body ignored)
[0x1001] DENY: Tor would prefer not to get more traffic from
this address for a while. (body ignored)
[0x1002] CONTROL: a NUL-terminated "identifier" string. The
pluggable transport proxy must use the "identifier" to access
the TransportControlPort. See the 'Association and identifier
creation' section below.
Parties MUST ignore command codes that they do not understand.
If the server receives a recognized command that does not parse, it
MUST close the connection to the client.
3.1.2. Command descriptions
3.1.2.1. USERADDR
An ASCII string holding the TCP/IP address of the client of the
pluggable transport proxy. A Tor bridge SHOULD use that address to
collect statistics about its clients. Recognized formats are:
1.2.3.4:5678
[1:2::3:4]:5678
(Current Tor versions may accept other formats, but this is a bug:
transports MUST NOT send them.)
The string MUST not be NUL-terminated.
3.1.2.2. TRANSPORT
An ASCII string holding the name of the pluggable transport used by
the client of the pluggable transport proxy. A Tor bridge that
supports multiple transports SHOULD use that information to collect
statistics about the popularity of individual pluggable transports.
The string MUST not be NUL-terminated.
Pluggable transport names are C-identifiers and Tor MUST check them
for correctness.
3.2. The new TransportControlPort protocol
The TransportControlPort protocol is as follows:
CONNECTIONID[16 bytes, big-endian]
COMMAND [2 bytes, big-endian]
BODYLEN [2 bytes, big-endian]
BODY [BODYLEN bytes]
Commands sent from the transport proxy to the bridge:
[0x0001] RATE_LIMITED: Message confirming that the rate limiting
request of the bridge was carried out successfully (body
ignored). See the 'Rate Limiting' section below.
[0x0002] NOT_RATE_LIMITED: Message notifying that the transport
proxy failed to carry out the rate limiting request of the
bridge (body ignored). See the 'Rate Limiting' section below.
Configuration commands sent from the bridge to the transport
proxy are:
[0x1001] NOT_ALLOWED: Message notifying that the CONNECTIONID
could not be matched with an authorized connection ID. The
bridge SHOULD shutdown the connection.
[0x1001] RATE_LIMIT: Carries information on how the pluggable
transport proxy should rate-limit its traffic. See the 'Rate
Limiting' section below.
CONNECTIONID should carry the connection identifier described in the
'Association and identifier creation' section.
Parties should ignore command codes that they do not understand.
3.3. Association and identifier creation
For Tor and a transport proxy to communicate using the
TransportControlPort, an identifier must have already been negotiated
using the 'CONTROL' command of Extended ORPort.
The TransportControlPort identifier should not be predictable by a
user who hasn't received a 'CONTROL' command from the Extended
ORPort. For this reason, the TransportControlPort identifier should
not be cryptographically-weak or deterministically created.
Tor MUST create its identifiers by generating 16 bytes of random
data.
4. Configuration commands
4.1. Rate Limiting
A Tor relay should be able to inform a transport proxy in real-time
about its rate-limiting needs.
This can be achieved by using the TransportControlPort and sending a
'RATE_LIMIT' command to the transport proxy.
The body of the 'RATE_LIMIT' command should contain two integers,
4 bytes each, in big-endian format. The two numbers should represent
the bandwidth rate and bandwidth burst respectively in 'bytes per
second' which the transport proxy must set as its overall
rate-limiting setting.
When the transport proxy sets the appropriate rate limiting, it
should send back a 'RATE_LIMITED' command. If it fails while setting
up rate limiting, it should send back a 'NOT_RATE_LIMITED' command.
After sending a 'RATE_LIMIT' command. the tor bridge MAY want to
stop pushing data to the transport proxy, till it receives a
'RATE_LIMITED' command. If, instead, it receives a 'NOT_RATE_LIMITED'
command it MAY want to shutdown its connections to the transport
proxy.
5. Authentication
To defend against cross-protocol attacks on the Extended ORPort,
proposal 213 defines an authentication scheme that should be used to
protect it.
If the Extended ORPort is enabled, Tor should regenerate the cookie
file of proposal 213 on startup and store it in
$DataDirectory/extended_orport_auth_cookie.
The location of the cookie can be overriden by using the
configuration file parameter ExtORPortCookieAuthFile, which is
defined as:
ExtORPortCookieAuthFile <path>
where <path> is a filesystem path.
XXX should we also add an ExtORPortCookieFileGroupReadable torrc option?
6. Security Considerations
Extended ORPort or TransportControlPort do _not_ provide link
confidentiality, authentication or integrity. Sensitive data, like
cryptographic material, should not be transferred through them.
An attacker with superuser access, is able to sniff network traffic,
and capture TransportControlPort identifiers and any data passed
through those ports.
Tor SHOULD issue a warning if the bridge operator tries to bind
Extended ORPort or TransportControlPort to a non-localhost address.
Pluggable transport proxies SHOULD issue a warning if they are
instructed to connect to a non-localhost Extended ORPort or
TransportControlPort.
7. Future
In the future, we might have pluggable transports which require the
_client_ transport proxy to use the TransportControlPort and exchange
control information with the Tor client. The current proposal doesn't
yet support this, but we should not add functionality that will
prevent it from being possible.
```
|
