[tor-dev] Proposal 190: Password-based Bridge Client Authorization
desnacked at gmail.com
Fri Nov 4 17:37:12 UTC 2011
Title: Password-based Bridge Client Authorization
Author: George Kadianakis
Created: 04 Nov 2011
Proposals 187 and 189 introduced the 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 password between the bridge user and bridge operator.
A proper bridge client authorization scheme should:
- request information from a client that only an authorized bridge
client would know.
- ensure that the shared secret sent by the bridge client during
the authorization can only be read and validated by the proper
bridge relay. This is important since the v3 link handshake which
authenticates the bridge to the client is carried out *after* the
bridge client authorization, which means that when the AUTHORIZE
cell is sent, the client might be actually speaking to a Man In
The bridge client authorization scheme presented in this proposal
is based on a shared password and attempts to satisfy both of the
If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants
to become authorized using a shared secret based on a password.
The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'.
'||', denotes concatenation.
'HMAC(k, m)', is the Hash-based Message Authentication Code of
message 'm' using 'k' as the secret key.
'H(m)', is a cryptographic hash function applied on a message 'm'.
'HASH_LEN', is the output size of the hash function 'H'.
3.2. Shared secret format
A bridge client and a bridge relay willing to use this
authorization scheme, should have already exchanged out-of-band
(for example, during the bridge credentials exchange) a shared
In this case, the shared secret of this scheme becomes:
shared_secret = H( H(bridge_identity_key) || ":" || password)
'bridge_identity_key', is the PKCS#1 ASN1 encoding of the bridge's
public identity key.
'":"', is the colon character (0x3a in UTF-8).
'password', is the bridge password.
3.3. Password-based authorization AUTHORIZE cell format
In password-based authorization, the MethodFields field of the
AUTHORIZE cell becomes:
'HMAC(shared_secret, tls_cert)' [HASH_LEN octets]
'HMAC(shared_secret, tls_cert), is the HMAC construction of the TLS
certificate of the bridge relay, using the shared secret of section
3.2 as the secret key.
3.4. Password-based authorization notes
Bridge implementations MUST reject clients who provide malformed
AUTHORIZE cells or HMAC values that do not verify the appropriate
Bridge implementations SHOULD provide an easy way to create and
change the bridge shared secret.
3.5. Security arguments
An adversary who does not know the 'shared_secret' of a bridge
cannot construct an HMAC that verifies its TLS certificate when
used with the correct 'shared_secret'.
An adversary who attempts to MITM the TLS connection of a bridge
user to steal the 'shared_secret' will instead steal an HMAC value
created by the 'tls_cert' of the TLS certificate that the attacker
used to MITM the TLS connection. Replaying that 'shared_secret'
value to the actual bridge will fail to verify the correct
The two above paragraphs resolve the requirements of the
Furthermore, an adversary who compromises a bridge, steals the
shared secret and attempts to replay it to other bridges of the
same bridge operator will fail since each shared secret has a
digest of the bridge's identity key baked in it.
The bridge's identity key digest also serves as a salt to counter
rainbow table precomputation attacks.
4. Tor implementation
The Tor implementation of the above scheme uses SHA256 as the hash
SHA256 also makes HASH_LEN equal to 32.
5.1. Do we need more authorization schemes?
The centuries-old problem with passwords is that humans can't get
their passwords right.
To avoid problems associated with the human condition, schemes
based on public key cryptography and certificates can be used. A
public and well tested protocol that can be used as the basis of a
future authorization scheme is the SSH "publickey" authorization
5.2. 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.
Without Nick Mathewson and Robert Ransom this proposal would
actually be specifying a useless and broken authentication scheme.
More information about the tor-dev