[tor-dev] Proposal: Bridge Detection Resistance against MITM-capable Adversaries

[George Kadianakis]

Julian Yon <julian at 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.