[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tor-dev
Subject:    Re: [tor-dev] Fallback Directory Handover
From:       teor <teor () riseup ! net>
Date:       2020-04-22 3:29:14
Message-ID: F431B8E5-B35F-4397-8873-C0062424D68E () riseup ! net
[Download RAW message or body]


> On 22 Apr 2020, at 12:27, Ian Goldberg <iang@uwaterloo.ca> wrote:
> 
> On Wed, Apr 22, 2020 at 11:56:54AM +1000, teor wrote:
>> a bad fallback guard can continue to manipulate its client's view of
>> the network
> 
> This is only true to the extent that the fallback guard can choose which
> of three still-valid consensuses to give to the client, right?

Not quite.

Clients tolerate recently-expired consensuses for some operations, up
to 72 hours in some cases.

When I last checked, TAILS set its system clock off the date in the
consensus it receives.

Clients also download authority certificates from fallback directory
mirrors. I think that's the whole trust path from the hard-coded
authority fingerprints, to the certificates, and then a valid consensus.

Since clients use an ORPort connection to download consensuses,
a malicious fallback directory mirror can also provide them with:
* the wrong date (triggering a clock skew warning)
* the wrong external IP address (not used for much)
* malicious directory documents
  * note that decompression and some parsing happens before the
     signature checks
* slow transfer speeds (like slowloris)

Using multiple fallbacks mitigates most of these issues.

T



_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[prev in list] [next in list] [prev in thread] [next in thread]