Julian Yon <julian@yon.org.uk> writes:

On 08/11/11 07:55, Jérémy Bobbio wrote:

...

On Tue, Nov 08, 2011 at 12:46:45AM +0100, George Kadianakis wrote:

...

Tor clients who use bridges and want to pin their SSL certificates must specify the bridge's SSL certificate fingerprint as in: Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 \ link_cert_fpr=38b0712e90bed729df81f2a22811d3dd89e91406d2522f4482ae4079e5245187

This starts to look like a lot of numbers. The kind that will be hard to hand out on paper without making a mistake…

In another thread (admittedly the wrong thread), there was brief discussion around the idea of using some sort of covert challenge/response handshake where the bridge proved that it knew the connection's SSL fingerprint. This would avoid having to distribute the fingerprint itself.

Hi there, I was not aware that the volume of the bridge credentials is an actual concern. I assumed that most people just receive the credentials through the Internet and copy/paste them to their torrc. With that in mind, I thought that passing an extra hash to the bridge user, and avoiding the need for steganography magic, is a better idea. Still, I can truncate the fingerprint to something like 12 bytes and use base32 so that it becomes more manageable. It will look like this: 'GM4GEMBXGEZGKOJQMJSWINZSHFSGMOBRMYZGCMQ=' It's not terribly bad. I'll update the proposal.

George had some concerns about this but it wasn't clear whether he was intending to write the idea off entirely or whether there was room to explore it further.

Julian

By the way, I'm not completely rejecting the tagging idea yet since it: a) needs no extra bridge credentials apart from the shared secret of prop190. b) doesn't need any maintenance in case of certificate expiration. Some arguments to consider against the tagging idea are: a) In the case of self-signed certificates, OpenSSL creates an 8-bytes random Serial number, and we would probably need something more than 8-bytes to tag. We might want to explore some x509v3 extensions like the "X509v3 {Subject,Authority} Key Identifier", which OpenSSL also sets by default. b) It complicates the scheme, and if not implemented/researched wisely it might make the scheme fingerprintable as well. c) We most probably won't be able to tag CA-signed certificates. The whole idea is to find a nice place on the certificate to stick a (possibly truncated) HMAC of the link public key, using the prop190 shared secret as the key. I will probably also mention this idea in the proposal, so that we can get some more opinions out of people; hoping that when the time for implementation comes we will know what to do.

Alright, posting an updated version of this proposal. It features shortened fingerprints and discussion on the certificate tagging. I hope 39 Base32 characters feel OK. If not, state your arguments and preferred solutions and I will update the proposal locally; I will try to not spam the list even more for fingerprint size changes. Inlining: Filename: XXX-mitm-bridge-detection-resistance.txt Title: Bridge Detection Resistance against MITM-capable Adversaries Author: George Kadianakis Created: 07 Nov 2011 Status: Open 1. Overview Proposals 187, 189 and 190 make the first steps toward scanning resistant bridges. They attempt to block attacks from censoring adversaries who provoke bridges into speaking the Tor protocol. An attack vector that hasn't been explored in those previous proposals is that of an adversary capable of performing Man In The Middle attacks to Tor clients. At the moment, Tor clients using the v3 link protocol have no way to detect such an MITM attack, and will gladly send an VERSIONS or an AUTHORIZE cell to the MITMed connection, thereby revealing the Tor protocol and thus the bridge. This proposal introduces a way for clients to detect an MITMed SSL connection, allowing them to protect against the above attack. 2. Motivation When the v3 link handshake protocol is performed, Tor's SSL handshake is performed with the server sending a self-signed certificate and the client blindly accepting it. This allows the adversary to perform an MITM attack. A Tor client must detect the MITM attack before he initializes the Tor protocol by sending a VERSIONS or an AUTHORIZE cell. A good moment to detect such an MITM attack is during the SSL handshake. To achieve that, bridge operators provide their bridge users with a hash digest of the public-key certificate their bridge is using for SSL. Bridge clients store that hash digest locally and associate it with that specific bridge. Bridge clients who have "pinned" a bridge to a certificate "fingerprint" can thereafter validate that their SSL connection peer is the intended bridge. Of course, the hash digest must be provided to users out-of-band and before the actual SSL handshake. Usually, the bridge operator gives the hash digest to her bridge users along with the rest of the bridge credentials, like the bridge's address and port. 3. Security implications Bridge clients who have pinned a bridge to a certificate fingerprint will be able to detect an MITMing adversary in timely fashion. If after detection they act as an innocuous Internet client, they can successfully remove suspicion from the SSL connection and subvert bridge detection. Pinning a certificate fingerprint and detecting an MITMing attacker does not automatically aleviate suspicions from the bridge or the client. Clients must have a behavior to follow after detecting the MITM attack so that they look like innocent Netizens. This proposal does not try to specify such a behavior. Implementation and use of this scheme does not render bridges and clients immune to scanning or DPI attacks. This scheme should be used along with bridge client authorization schemes like the ones detailed in proposal 190. 4. Tor Implementation 4.1. Certificate fingerprint creation The certificate fingerprints used on this scheme MUST be computed by applying the SHA256 cryptographic hash function upon the ASN.1 DER encoding of a public-key certificate, then truncating the hash output to 12 bytes, encoding it to RFC4648 Base32 and omitting any trailing padding '='. 4.2. Bridge side implementation Tor bridge implementations SHOULD provide a command line option that exports a fully equipped Bridge line containing the bridge address and port, the link certificate fingerprint and any other enabled Bridge options, so that bridge operators can easily send it to their users. In the case of expiring SSL certificates, Tor bridge implementations SHOULD warn the bridge operator a sensible amount of time before the expiration, so that she can warn her clients and potentially rotate the certificate herself. 4.3. Client side implementation Tor client implementations MUST extend their Bridge line format to support bridge SSL certificate fingerprints. The new format is: Bridge <method> <address:port> [["keyid="]<id-fingerprint>] \ ["shared_secret="<shared_secret>] ["link_cert_fpr="<fingerprint>] where <fingerprint> is the bridge's SSL certificate fingerprint in hexademical encoding. Tor clients who use bridges and want to pin their SSL certificates must specify the bridge's SSL certificate fingerprint as in: Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 \ link_cert_fpr=GM4GEMBXGEZGKOJQMJSWINZSHFSGMOBRMYZGCMQ 4.4. Implementation prerequisites Tor bridges currently rotate their SSL certificates every 2 hours. This not only acts as a fingerprint for the bridges, but it also acts as a blocker for this proposal. Tor trac ticket #4390 and proposal YYY were created to resolve this issue. 5. Other ideas 5.1. Certificate tagging using a shared secret Another idea worth considering is having the bridge use the shared secret from proposal 190 to embed a "secret message" on her certificate, which could only be understood by a client who knows that shared secret, essentially authenticating the bridge. Specifically, the bridge would "tag" the Serial Number (or any other covert field) of her certificate with the (potentially truncated) HMAC of her link public key, using the shared secret of proposal 190 as the key: HMAC(shared_secret, link_public_key). A client knowing the shared secret would be able to verify the 'link_public_key' and authenticate the bridge, and since the Serial Number field is usually composed of random bytes a probing attacker would not notice the "tagging" of the certificate. Arguments for this scheme are that it: a) doesn't need extra bridge credentials apart from the shared secret of prop190. b) doesn't need any maintenance in case of certificate expiration. Arguments against this scheme are: a) In the case of self-signed certificates, OpenSSL creates an 8-bytes random Serial number, and we would probably need something more than 8-bytes to tag. There are not many other covert fields in SSL certificates mutable by vanilla OpenSSL. b) It complicates the scheme, and if not implemented and researched wisely it might also make it fingerprintable. c) We most probably won't be able to tag CA-signed certificates. 6. Discussion 6.1. In section 4.1, why do you truncate the SHA256 output to 12 bytes?! Bridge credentials are frequently propagated by word of mouth or are physically written down, which renders the occult Base64 encoding unsatisfactory. The 104 characters Base32 encoding or the 64 characters hex representation of the SHA256 output would also be too much bloat. By truncating the SHA256 output to 12 bytes and encoding it with Base32, we get 39 characters of readable and easy to transcribe output, and sufficient security. Finally, dividing '39' by the golden ratio gives us about 24.10! 6. Acknowledgements Thanks to Robert Ransom for his great help and suggestions on devising this scheme and writing this proposal!