mirror of
https://github.com/torproject/torspec.git
synced 2024-12-12 04:35:37 +00:00
104 lines
3.4 KiB
Plaintext
104 lines
3.4 KiB
Plaintext
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.
|
|
|