[tor-dev] Bootstrapping with a very inaccurate clock

[Michael Rogers <michael@xxxxxxxxxxxxxxxx>]

Hello again,

Apologies for starting two threads in quick succession.

First of all I want to say thank you for all the improvements in 
handling clock skew between 0.3.5 and 0.4.5. We recently migrated Briar 
to 0.4.5, and some situations that are common on mobile, such as the 
system clock being configured with the wrong timezone, are now much less 
likely to affect Tor connectivity (except when using obfs4).

When the system clock is very far behind real time, Tor's clock skew 
events enable us to warn the user to check their time and date settings. 
When the clock is ahead of real time by up to a day, there are no clock 
skew events but Tor can bootstrap. But when the clock is several days 
ahead of real time, there are no clock skew events and Tor gets stuck 
boostrapping at 14%.

At the moment we're having trouble distinguishing this situation from 
other situations that might cause bootstrapping to get stuck, such as 
access to the Tor network being blocked. So ideally we'd like to be able 
to detect that the clock is the problem and ask the user to fix it.

I should say that this is probably a rare situation. Old devices that 
haven't been turned on for a while sometimes reset their clocks to a 
point in the distant past, but I've never seen a device spontaneously 
change its clock to a point in the distant future. Still, people do mess 
around with the time and date settings so we'd like to detect and fix 
this issue if possible.

Is there any way for Tor to tell, during bootstrapping, that the system 
clock appears to be far ahead of real time?

Thanks,
Michael

Attachment: OpenPGP_0x11044FD19FC527CC.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

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