So in this thread I will propose that htpdate is better option then NTP for users that can’t use Tor (even though I don’t fit in this group).
A Kicksecure user may not be able to use Tor and by extension sdwdate for various reasons:
- Cant use Tor as it is blocked (Oppressive Govt or Strict ISP)
- Doesn’t want to use Tor but wants everything else that kicksecure provides as a hardened Debian distro (Freedom & User Choice)
- Prefers to not use Tor on kicksecure HOST. Would rather use Tor in VM like Whonix or TBB only (Freedom & User Choice)
Htpdate vs NTP
- Avoids government time servers
You can use pool of HTTP or HTTPS websites rather then rather than NIST, USNO, or other government-run NTP pools.
- Firewall-friendly
Uses TCP ports 80/443 (regular web traffic), not UDP 123. Passes through firewall setups that block NTP.
- No reliance on third party repos
Available directly in Debian apt without enabling additional repos
I Challenge Thee
- Can check against multiple sources like sdwdate
htpdate accepts up to 16 hosts on the command line, though 3 to 5 servers are recommended for redundancy and accuracy
- Traffic identification
Looks like regular web browsing (TCP port 80/443) rather then NTP via UDP/123 which is instantly recognizable.
- Correlation risk
Duplicate of above it blends into normal web traffic, doesn’t signify that someone is just booting up their device or syncing time.
- Participation barrier
Duplicate of previouslt mentioned. Any web server can participate as compared to only NTP configured servers and pools.
Ultimately what it comes down to how htpdate is Decentralized rather then NTP unauthenticated which structure is highly centralized.
Best defense against active attackers is with authentication (htpdate + HTTPS or NTP + NTS) but if clock is way off CA certs will break.
- Fallback Methods?
I dont see a fallback method if HTTPS fails to resort to HTTP. Maybe setting HTTPS servers first then HTTP last so first it tries more secure method and if time is too old it with go the HTTP route.
- Boot Clock Randomization
Using Boot Clock Randomization, i.e. after boot, the clock is set randomly between 0 and 180 seconds into the past or future.
Boot Clock Randomization
Both HTTP and HTTPS should still work with this unless the user/code changes to make the randomization longer.