Mitigate attack by active network adversary on automated time sync + replayed Tor consensus
As we noticed on !681 (comment 180870), the new time sync mechanism added for #18717 (closed) re-introduces some security issues that we had gotten rid of when we removed tordate
.
An active network adversary can feed Tails an old date/time, then replay a Tor consensus that was valid at that time. (Replaying an old Tor consensus is bad because it could include bad relays that were since removed, e.g. sybil attacks. So if an attacker used to control a large part of the network, but this was fixed in the Tor network, the attacker replaying the old consensus will fool our user's tor client, which will use bad relays.)
Then htpdate will either succeed or fail at setting the correct time:
-
If htpdate succeeds, then tor will notice the time has changed and its consensus is outdated, and presumably will attempt to retrieve a newer consensus. At that point the best the attacker can do is block that or replay an old consensus that tor will reject. This is a denial of service that such an attacker could do by merely blocking network traffic anyway ⇒ no regression here.
-
If htpdate fails, e.g. because the TLS certificates used by the servers in our HTP pool were not valid at that earlier date yet: Tor is still working, oops. Do we have anything in place to mitigate this attack? To be investigated.
This reasoning applied just the same to tordate, so this is not a regression compared to pre-Tails 4.22 state (note that our design doc about tordate assumed that htpdate would succeed and save the day). However, it is a regression compared to current Tails (4.26).
Parent issue: #5774
This is our reasoning (2022-02-22):
Why replaying an old consensus seems like a Bad Thing?
It could include bad relays that were since removed, e.g. sybil attacks.
So if an attacker used to control a large part of the network, but this was fixed in the Tor network, the attacker replaying the old consensus will fool our user's tor client, which will use bad relays
We don't know what exactly an adversary can do by replying an old consensus:
- how long until the tor client somehow notices the consensus is outdated, e.g. because it tries to get a fresh consensus or realizes it has outdated info (pubkeys?) to connect to DirAuths?
Possible mitigations
1: Reject date from the connectivity-check service that is earlier than /etc/amnesia/version
it's Simple and safe: there is no way such a date could be valid even for a user which is up-to-date with the latest Tor, this is still a month-long window. ie: an attacker that has been evicted from Tor network can continue its attack for 1 more month
ACTION:
-
implement this, regardless of whether we add more mitigations, because for some of them this caps the amount of extra attack surface these mitigations offer the attacker (by disabling verifications). [boyska]
Is this mitigation enough? We don't know, and there's clearly some tradeoff. We will come back at it after we have investigated other proposals. If some of them are easy-ish to implement, we don't need to think about it.
2: Make htpdate accept TLS certificates that are not valid yet
Assumptions:
-
we assume that, when we run htpdate, the time on our system is basically untrusted (we've got it through plaintext http!).
-
we trust (all? some? only LetsEncrypt?) CAs not to release certificates whose valid-after is in the future.
But we should check if this assumption is correct, e.g. in CAB guidelines. https://cabforum.org/
Optional bonus: if htpdate fails to get consensus on the time, set the date to the latest valid-after we got.
Cons: have to wire into low-level TLS implementation to get the info we want and to override the single check we want to disable.
Conclusion: This is strictly harder than Proposal 3, so - since we are very concerned about implementation difficulty - let's ignore this for now.
3: Make htpdate accept TLS certificates from any time span
Rationale: simpler than the previous one to implement. What guarantees can it give us?
To attack this, the adversary would need to have taken hold of (possibly old versions of) TLS key pairs for at least 1 server in each of our HTP pools, which sets the bar pretty high.
Combine this with the 1st mitigation, that is, reject date that's earlier than Tails' build date ⇒ gives an upper cap to how old stuff the attacker can replay (we're not sure how useful that is but it avoids having to reason about whether we can skip this check).
Utility: https://expired.badssl.com/
ACTION:
-
investigate if we can ask a commonly used (because security, and maybe because network fingerprint) HTTPS library to validate certificates properly EXCEPT valid-{before,after}. Is this actually simple? The curl commandline doesn't seem to provide this, neither does the libcurl "easy" interface (https://curl.se/libcurl/c/CURLOPT_CERTINFO.html)
ACTION: boyska makes a first round at it. Goal: provide data so that we can discuss this while we're in time for 4.29
4: detect that we have an old consensus
Having an old consensus doesn't make our tor works wonderfully. It's not exactly like when an attacker is MitM'ing your SSL connection to something. So, can we detect this kind of behaviour in some way, and fail hard if that's the case?
Is it possible to connect to an Onion service with an old clock + matching Tor consensus? If not, we can detect that and ask the user to set the clock.
ACTION:
-
ask tor onion service v3 developers (David Goulet) the above question [intrigeri]
Only relevant in easy mode where we trust network time.