[tor-dev] Proposal 190: Password-based Bridge Client Authorization

[George Kadianakis]

Robert Ransom <rransom.8774 at gmail.com> writes:

> On 2012-01-17, Nick Mathewson <nickm at alum.mit.edu> wrote:
>> On Sun, Nov 6, 2011 at 9:12 PM, George Kadianakis <desnacked at 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.