[tor-dev] Proposal 190: Password-based Bridge Client Authorization
desnacked at gmail.com
Mon Nov 7 02:12:43 UTC 2011
Let's try again this proposal with a more Keep It Simple, Stupid!
After deciding that MITM is not in our threat model at the moment,
this new proposal 190 doesn't even try to protect against an MITM
adversary! It's slicker, faster and maybe even better.
Title: Bridge Client Authorization Based on a Shared Secret
Author: George Kadianakis
Created: 04 Nov 2011
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.
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]
'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 hexademical encoding.
Tor bridge implementations MUST support the boolean
'BridgeRequireClientSharedSecretAuthorization' configuration file
option which enables bridge client authorization based on a shared
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 hexademical
Tor clients who use bridges with shared-secret-based client
authorization must specify the bridge's shared secret as in:
Bridge 22.214.171.124 shared_secret=934caff420aa7852b855
5.1. What should actually happen when a bridge rejects an AUTHORIZE
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.
Thanks to Nick Mathewson and Robert Ransom for the help and
suggestions while writing this proposal.
More information about the tor-dev