Proposal 190: Password-based Bridge Client Authorization
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. - 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 Middle. 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 password. In this case, the shared secret of this scheme becomes: shared_secret = H( H(bridge_identity_key) || ":" || password) where: '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] where: '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 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 'tls_cert'. 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. 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 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. 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 protocol. 5.2. 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 Without Nick Mathewson and Robert Ransom this proposal would actually be specifying a useless and broken authentication scheme. Thanks!
On 2011-11-04, George Kadianakis <desnacked@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 password.
In this case, the shared secret of this scheme becomes:
shared_secret = H( H(bridge_identity_key) || ":" || password)
where:
'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 strings.
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]
where:
'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 'tls_cert'.
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 protocol.
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 modulus efficiently.
5.2. 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.
Robert Ransom
On 2011-11-04, Robert Ransom <rransom.8774@gmail.com> wrote:
On 2011-11-04, George Kadianakis <desnacked@gmail.com> wrote:
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 protocol.
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 modulus efficiently.
Um. On second thought, this is just freaking ridiculous (especially my paragraph). We don't want each client to have to generate a public-key authentication keypair and send its public key to the bridge in advance; that would be a nightmare to implement with our current bridge infrastructure. So the only sensible ways to use public-key authentication seems to be to give the same secret key to every authorized client (i.e. distribute it like a password) (see Telex), and then we might as well use a (shorter) shared-secret password (unless we need magic features of a specific cryptosystem like the ‘public-key steganography’ used in Telex). Robert Ransom
Let's try again this proposal with a more Keep It Simple, Stupid! approach. 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. Inlining: Filename: 190-shared-secret-bridge-authorization.txt Title: Bridge Client Authorization Based on a Shared Secret Author: George Kadianakis Created: 04 Nov 2011 Status: Open 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 hexademical 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 hexademical 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.
On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis <desnacked@gmail.com> wrote:
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.
No, dumping the HMAC seems like a step backwards. In practice, bridges are needed exactly in those cases where we're worried about active attacks between clients and the Tor network. There's no point in revising a protocol proposal to be MORE vulnerable to MITM; instead, we need one that is less vulnerable. Marking this proposal needs-revision. Not sure what the actual solution is though. One option might be to look for a way to signal (undetectably) to the client that the server knows what it's doing as part of the TLS handshake. For example, by building the ServerHello.random structure such that instead of having 28 random bytes and 4 bytes of time, it has 16 random bytes, 4 bytes of time, and 12 bytes based on a HMAC of (the 16 random bytes, the 4 time bytes, the ClientHello.Random, and the certificate that it will send). Yuck! But it might work. It would need analysis, I guess. I'm probably being too telegraphic here; I should try to expand this into a real idea if people don't think it's a total nonstarter for some reason. yrs, -- Nick
On 2012-01-17, Nick Mathewson <nickm@alum.mit.edu> wrote:
On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis <desnacked@gmail.com> wrote:
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.
No, dumping the HMAC seems like a step backwards. In practice, bridges are needed exactly in those cases where we're worried about active attacks between clients and the Tor network. There's no point in revising a protocol proposal to be MORE vulnerable to MITM; instead, we need one that is less vulnerable.
Proposal 190 is only meant to resist identification of a bridge as a bridge by an attacker actively probing it. A MITM attacker is far more likely to be trying to identify the client as a Tor client, so clients which need to resist MITM attacks must detect them before reaching the point in the protocol where it would send the AUTHORIZE cell (thereby identifying it as a Tor client).
Marking this proposal needs-revision. Not sure what the actual solution is though. One option might be to look for a way to signal (undetectably) to the client that the server knows what it's doing as part of the TLS handshake. For example, by building the ServerHello.random structure such that instead of having 28 random bytes and 4 bytes of time, it has 16 random bytes, 4 bytes of time, and 12 bytes based on a HMAC of (the 16 random bytes, the 4 time bytes, the ClientHello.Random, and the certificate that it will send). Yuck! But it might work. It would need analysis, I guess.
With that hack on top of the v3 protocol, any client able to detect that a bridge is not being MITMed can impersonate the bridge through the TLS handshake, until after the (honest, victim) client speaks the Tor protocol at the fake bridge. The solution is: * Add a v4 link protocol in which the bridge/relay publishes a list of fingerprints and cert-chain positions of link certificates in its descriptor, and the client verifies that the TLS server it's connecting to presents a cert chain such that one certificate's fingerprint and position in the cert chain matches one of the fingerprint/position pairs in the server descriptor. * Add a v4link=(FINGERPRINT,POSITION,IS-POSITION-RELATIVE-TO-ROOT-OR-LEAF),... item to the Bridge line parser. * ... * Now TLS takes care of MITM detection for us, because we're using it correctly for the first time since the v1 handshake. Profit. * Add EXTEND2 cells so relay-to-relay connections can use v4 links. Robert Ransom
On Tue, Jan 17, 2012 at 1:28 PM, Robert Ransom <rransom.8774@gmail.com> wrote:
With that hack on top of the v3 protocol, any client able to detect that a bridge is not being MITMed can impersonate the bridge through the TLS handshake, until after the (honest, victim) client speaks the Tor protocol at the fake bridge.
Seems mostly harmless; the only point of a shared secret there is to keep scanning from working. Anybody who tries the above attack already know that the bridge is there; all they learn is that the client knew too, which they probably could have figured out as an eavesdropper. -- Nick
On 2012-01-18, Nick Mathewson <nickm@alum.mit.edu> wrote:
On Tue, Jan 17, 2012 at 1:28 PM, Robert Ransom <rransom.8774@gmail.com> wrote:
With that hack on top of the v3 protocol, any client able to detect that a bridge is not being MITMed can impersonate the bridge through the TLS handshake, until after the (honest, victim) client speaks the Tor protocol at the fake bridge.
Seems mostly harmless; the only point of a shared secret there is to keep scanning from working. Anybody who tries the above attack already know that the bridge is there; all they learn is that the client knew too, which they probably could have figured out as an eavesdropper.
Censoring MITM attackers tend to MITM all SSL/TLS connections, regardless of their destination. No one would benefit from performing a targeted MITM attack on a bridge, even if we implemented bridge passwords in such a way that a MITM attacker can obtain the password needed to connect to (and use) a bridge. Robert Ransom
Robert Ransom <rransom.8774@gmail.com> writes:
On 2012-01-17, Nick Mathewson <nickm@alum.mit.edu> wrote:
On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis <desnacked@gmail.com> wrote:
<snip>
Marking this proposal needs-revision. Not sure what the actual solution is though. One option might be to look for a way to signal (undetectably) to the client that the server knows what it's doing as part of the TLS handshake. For example, by building the ServerHello.random structure such that instead of having 28 random bytes and 4 bytes of time, it has 16 random bytes, 4 bytes of time, and 12 bytes based on a HMAC of (the 16 random bytes, the 4 time bytes, the ClientHello.Random, and the certificate that it will send). Yuck! But it might work. It would need analysis, I guess.
With that hack on top of the v3 protocol, any client able to detect that a bridge is not being MITMed can impersonate the bridge through the TLS handshake, until after the (honest, victim) client speaks the Tor protocol at the fake bridge.
The solution is:
* Add a v4 link protocol in which the bridge/relay publishes a list of fingerprints and cert-chain positions of link certificates in its descriptor, and the client verifies that the TLS server it's connecting to presents a cert chain such that one certificate's fingerprint and position in the cert chain matches one of the fingerprint/position pairs in the server descriptor.
* Add a v4link=(FINGERPRINT,POSITION,IS-POSITION-RELATIVE-TO-ROOT-OR-LEAF),... item to the Bridge line parser.
* ...
* Now TLS takes care of MITM detection for us, because we're using it correctly for the first time since the v1 handshake. Profit.
* Add EXTEND2 cells so relay-to-relay connections can use v4 links.
AFAICT this is the concept of proposal 191, but using certificate chains instead of single certificates. Before extending proposal 191 to use certificate chains, we should look at whether HTTPS servers with certificate chains whose roots are _not_ signed by a real CA are commonplace in the Internet (not many volunteers will be able to set up bridges with CA-authenticated certificate chains.). We should also consider whether authenticating certificate chains provides more security than authenticating single certificates.
Nick Mathewson <nickm@alum.mit.edu> writes:
On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis <desnacked@gmail.com> wrote:
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.
No, dumping the HMAC seems like a step backwards. In practice, bridges are needed exactly in those cases where we're worried about active attacks between clients and the Tor network. There's no point in revising a protocol proposal to be MORE vulnerable to MITM; instead, we need one that is less vulnerable.
Marking this proposal needs-revision. Not sure what the actual solution is though. One option might be to look for a way to signal (undetectably) to the client that the server knows what it's doing as part of the TLS handshake. For example, by building the ServerHello.random structure such that instead of having 28 random bytes and 4 bytes of time, it has 16 random bytes, 4 bytes of time, and 12 bytes based on a HMAC of (the 16 random bytes, the 4 time bytes, the ClientHello.Random, and the certificate that it will send). Yuck! But it might work. It would need analysis, I guess.
Hm, which problem is this idea a solution to? I seem to recall that the biggest issue with 190 trying to protect against MITM attacks, was the fact that even though the MITM won't be able to capture the bridge's password, the Client will still happily send an AUTHORIZE cell to the MITM, revealing the fact that it's a connection to a Tor bridge. I'm not sure if your idea tries to solve the above problem, but an HMAC of (the 16 random bytes, the 4 time bytes, the ClientHello.Random, and the certificate that it will send) looks forgeable by an adversary, leaving the Client to believe that he is speaking with the correct Tor bridge. By the way, section 5.1 of proposal 191 tries to solve the above problem by tagging the SSL handshake with the shared-secret of proposal 190. Also, I doubt that vanilla OpenSSL will let us toy with {Server,Client}Hello.Random. I think that's one of the reasons that Telex ended up with an OpenSSL patch [0].
I'm probably being too telegraphic here; I should try to expand this into a real idea if people don't think it's a total nonstarter for some reason.
yrs,
So, after considering the above problems, we decided to split the bridge-password problem into two parts, proposal 190 which authenticates the Client to the Bridge, and proposal 191 which authenticates the Bridge to the Client. Building on the above thought, if proposals 190 and 191 authenticate the two parties based on trusted credentials shared off-band, the v3 link protocol becomes somewhat obsolete, and we are talking about a new link protocol which two-way authenticates the bridge and the bridge client based on shared-secrets. [0]: Did the Telex people clean up the patch, generalize it, and post it in openssl-dev? Having configurable {Server,Client}Hello.Random in a future version of OpenSSL would be neat.
On Tue, Jan 17, 2012 at 08:43:00PM +0200, George Kadianakis wrote:
[0]: Did the Telex people clean up the patch, generalize it, and post it in openssl-dev? Having configurable {Server,Client}Hello.Random in a future version of OpenSSL would be neat.
At USENIX Security, Adam opined that openssl's callback mechanism should be able to do this with no patches to the source. (I think there was one part of Telex that would still need patches to openssl, but I don't think that was it.) You basically request a callback right after the clienthello.random is generated, and in the callback, overwrite the value. Or something like that; I don't remember exactly. - Ian
On 2012-01-17, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Tue, Jan 17, 2012 at 08:43:00PM +0200, George Kadianakis wrote:
[0]: Did the Telex people clean up the patch, generalize it, and post it in openssl-dev? Having configurable {Server,Client}Hello.Random in a future version of OpenSSL would be neat.
At USENIX Security, Adam opined that openssl's callback mechanism should be able to do this with no patches to the source. (I think there was one part of Telex that would still need patches to openssl, but I don't think that was it.) You basically request a callback right after the clienthello.random is generated, and in the callback, overwrite the value. Or something like that; I don't remember exactly.
In a Telex TLS connection, the client's DH secret key is derived from the ECDH shared secret between the client's Telex ECDH key and the Telex server's ECDH key. (This has the unfortunate side effect that a client attempting to find Telex servers gives up forward secrecy for its TLS connections.) This may be the part of Telex which requires an OpenSSL patch. Robert Ransom
On Wed, Jan 18, 2012 at 07:07:08AM +0000, Robert Ransom wrote:
On 2012-01-17, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Tue, Jan 17, 2012 at 08:43:00PM +0200, George Kadianakis wrote:
[0]: Did the Telex people clean up the patch, generalize it, and post it in openssl-dev? Having configurable {Server,Client}Hello.Random in a future version of OpenSSL would be neat.
At USENIX Security, Adam opined that openssl's callback mechanism should be able to do this with no patches to the source. (I think there was one part of Telex that would still need patches to openssl, but I don't think that was it.) You basically request a callback right after the clienthello.random is generated, and in the callback, overwrite the value. Or something like that; I don't remember exactly.
In a Telex TLS connection, the client's DH secret key is derived from the ECDH shared secret between the client's Telex ECDH key and the Telex server's ECDH key. (This has the unfortunate side effect that a client attempting to find Telex servers gives up forward secrecy for its TLS connections.) This may be the part of Telex which requires an OpenSSL patch.
Yes, that seems likely. (Note, though, that only the *wrapper* TLS loses forward secrecy, but what was inside that wrapper came out of the Telex proxy as plaintext, anyway. If the client actually connects to a TLS server as the covert destination, that TLS connection is perfectly normal.) - Ian
participants (5)
-
George Kadianakis -
George Kadianakis -
Ian Goldberg -
Nick Mathewson -
Robert Ransom