-
Notifications
You must be signed in to change notification settings - Fork 84
/
190-shared-secret-bridge-authorization.txt
103 lines (68 loc) · 3.37 KB
/
190-shared-secret-bridge-authorization.txt
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
Filename: 190-shared-secret-bridge-authorization.txt
Title: Bridge Client Authorization Based on a Shared Secret
Author: George Kadianakis
Created: 04 Nov 2011
Status: Obsolete
Notes: This is obsoleted by pluggable transports.
1. Overview
Proposals 187 and 189 introduced AUTHORIZE and AUTHORIZED cells.
Their purpose is to make bridge relays scanning-resistant against
censoring adversaries capable of probing hosts to observe whether
they speak the Tor protocol.
This proposal specifies a bridge client authorization scheme based
on a shared secret between the bridge user and bridge operator.
2. Motivation
A bridge client authorization scheme should only allow clients who
show knowledge of a shared secret to talk Tor to the bridge.
3. Shared-secret-based authorization
3.1. Where do shared secrets come from?
A shared secret is a piece of data known only to the bridge
operator and the bridge client.
It's meant to be automatically generated by the bridge
implementation to avoid issues with insecure and weak passwords.
Bridge implementations SHOULD create shared secrets by generating
random data using a strong RNG or PRNG.
3.2. AUTHORIZE cell format
In shared-secret-based authorization, the MethodFields field of the
AUTHORIZE cell becomes:
'shared_secret' [10 octets]
where:
'shared_secret', is the shared secret between the bridge operator
and the bridge client.
3.3. Cell parsing
Bridge implementations MUST reject any AUTHORIZE cells whose
'shared_secret' field does not match the shared secret negotiated
between the bridge operator and authorized bridge clients.
4. Tor implementation
4.1. Bridge side
Tor bridge implementations MUST create the bridge shared secret by
generating 10 octets of random data using a strong RNG or PRNG.
Tor bridge implementations MUST store the shared secret in
'DataDirectory/keys/bridge_auth_ss_key' in hexadecimal encoding.
Tor bridge implementations MUST support the boolean
'BridgeRequireClientSharedSecretAuthorization' configuration file
option which enables bridge client authorization based on a shared
secret.
If 'BridgeRequireClientSharedSecretAuthorization' is set, bridge
implementations MUST generate a new shared secret, if
'DataDirectory/keys/bridge_auth_ss_key' does not already exist.
4.2. Client side
Tor client implementations must extend their Bridge line format to
support bridge shared secrets. The new format is:
Bridge [<method>] <address[:port]> [["keyid="]<id-fingerprint>] ["shared_secret="<shared_secret>]
where <shared_secret> is the bridge shared secret in hexadecimal
encoding.
Tor clients who use bridges with shared-secret-based client
authorization must specify the bridge's shared secret as in:
Bridge 12.34.56.78 shared_secret=934caff420aa7852b855
5. Discussion
5.1. What should actually happen when a bridge rejects an AUTHORIZE
cell?
When a bridge detects a badly formed or malicious AUTHORIZE cell,
it should assume that the other side is an adversary scanning for
bridges. The bridge should then act accordingly to avoid detection.
This proposal does not try to specify how a bridge can avoid
detection by an adversary.
6. Acknowledgements
Thanks to Nick Mathewson and Robert Ransom for the help and
suggestions while writing this proposal.