[tor-dev] Proposal 190: Password-based Bridge Client Authorization
rransom.8774 at gmail.com
Fri Nov 4 19:31:20 UTC 2011
On 2011-11-04, George Kadianakis <desnacked at gmail.com> wrote:
> Filename: 190-password-bridge-authorization.txt
> Title: Password-based Bridge Client Authorization
> Author: George Kadianakis
> Created: 04 Nov 2011
> Status: Open
> 1. Overview
> 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.
> 2. Motivation
> A proper bridge client authorization scheme should:
> - request information from a client that only an authorized bridge
> client would know.
- request information from a client that only an authorized client
of the bridge 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.
The shared secret cannot be read by the bridge relay, only validated.
(That's a feature.)
> 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 Middle.
And the reason that the client might be speaking to a MITM attacker is
that the client has no way to determine whether it should accept
whatever link certificate chain it receives. Hmm.
> The bridge client authorization scheme presented in this proposal
> is based on a shared password and attempts to satisfy both of the
> above requirements.
> 3. Design
> 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'.
> 3.1. Notation
> '||', 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.
At the time that the client needs to compute shared_secret from
password (before it receives a CERT cell from the bridge for the first
time), the client does not know the bridge's identity key.
There is no reason to have shared_secret and password be different
> 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.
Which TLS certificate, encoded in what way? (The bridge may send a
CA-signed certificate and its issuer chain.)
> 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
> TLS certificate.
> 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
An adversary who MITMs the TLS connection and receives a Tor AUTHORIZE
cell will know that the client is trying to connect to a Tor bridge.
Should the client send a string of the form "GET
/?q=correct+horse+battery+staple\r\n\r\n" instead of an AUTHORIZE
cell, where "correct+horse+battery+staple" is a semi-plausible search
phrase derived from the HMAC in some way?
> The two above paragraphs resolve the requirements of the
> 'Motivation' section.
> 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.
Where do passwords come from?
In my opinion, each Tor bridge configured to require a password should
generate its own password, as a sufficiently long random string. 80
bits of entropy should be far more than enough for a bridge password.
In this case, different bridges should never have the same password.
> The bridge's identity key digest also serves as a salt to counter
> rainbow table precomputation attacks.
Precomputation should not be useful if each password contains 80 bits
of entropy. The bridge's identity key digest is not used in the
protocol specified above; only the identity key itself.
> 4. Tor implementation
> The Tor implementation of the above scheme uses SHA256 as the hash
> function 'H'.
> SHA256 also makes HASH_LEN equal to 32.
> 5. Discussion
> 5.1. Do we need more authorization schemes?
> Probably yes.
> The centuries-old problem with passwords is that humans can't get
> their passwords right.
Passwords used for this purpose should be provided to clients as part
of a Bridge torrc line, in either written or electronic form. The
user will not retype them every time he/she/it starts Tor.
> 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
Secret keys for DSA (with a fixed group) and EC-based signature
schemes can be short enough to be fairly easy to transport. Secret
keys for RSA are a PITA to transport, unless you either (a) specify a
deterministic key-generation procedure, or (b) make the public key
available to all clients somehow, and provide enough information to
clients intended to access a bridge that the client can factor the
> 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.
More information about the tor-dev