Should users use htpdate rather then NTP if they cant use sdwdate?

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.

Using Kicksecure without Tor. Can Kicksecure be used without Tor?

sdwdate is reliant on a functioning Tor because it utilizes onions, which necessitates a Tor connection.

I don’t really like this idea all that much. It’s a serious reduction in security compared to sdwdate, and falling back to a less secure mechanism when a more secure one fails is generally bad for end-users, since it assumes that they can live with the lessened security. It’s better to fall back to “things break and the user is left to figure it out” if a secure mechanism breaks, because it gives the user the opportunity to decide for themselves what they can do to work around issues without getting compromised. (For instance, maybe they have an analog clock on their wall that they can use as a time source.)

1 Like

or making NTP as fallback mechanism when needed to fix itself.
Kicksecure on hardware - sdwdate clock always broken on direct hard drive

So if a user cant use sdwdate you would suggest enable NTP?

Obviously sdwdate is the best option as described in its design, but I’m taking an opposing viewpoint in argument for users that cant use Tor but want to use kicksecure for everything else it provides.

No. I would suggest not getting time from the Internet at all and getting it from some other source, preferably not Internet-connected (wall clock, non-smart watch, get-time-and-date phone number, sundial, sun position in the sky, etc.). It’s rare for someone to have no way of accurately telling time other than the Internet, and once you have your clock right enough, you can access a few different sites that say what time it is at the moment over TLS and get a statistically likely correct exact time from that.

2 Likes

So would this be a bad time to plug the F-91W watch? :joy::laughing::rofl: