Hi,
[please don't Cc me, I read the list]
It seems that this has slipped through the cracks... sorry!
bancfc@??? wrote (12 Sep 2014 01:04:41 GMT) :
> The current secure timesyncing solution has some serious implications for security
> because they rely on an untrusted model using clearnet servers. Even though SSL is
> used, the broken CA model negates its protection and the adversary could easily MITM
> requests and send fake replies or potentially exploit the time synchronizer process
> running on the system.
I assume you're talking of the htpdate part of our current time
synchronization solution, since it's the only part where your note
about the CA cartel makes sense as far as I understand it.
Note that those connections go through a Tor SocksPort that thas the
IsolateDestAddr and IsolateDestPort options enabled. So, to perform
such an attack via MitM against htpdate's connections, an adversary
will need to do that in several places at the same time; quoting the
corresponding bits of our design doc:
It also uses several different pools of time sources, and if there
are too many that fail for any given pool, e.g. because of failed
certificate checking or being unreachable, the pool is considered to
be potentially compromised and htpdate aborts.
I easily admit I didn't think very hard about it, but given this,
I fail to see how an attacker can "easily MITM" those requests in
a way that effectively affects a running Tails much. Am I missing
something, or did you overlook this aspect?
> Use of Hidden Service descriptors to obtain more accurate time: [...]
Thanks a lot for thinking through this potential other solution.
How does it play with the "next-generation" (ahem) time sync'ing
design we have in mind? It's described there:
https://tails.boum.org/blueprint/robust_time_syncing/
Note that in this new design, htpdate is only used to detect replayed
Tor consensus.
Cheers,
--
intrigeri
