New attacks on Network Time Protocol can defeat HTTPS and create chaos

Turning the clock back won't help defeat HTTPS if the root certificate store doesn't contain obsolete certs. The root certs will become invalid before their validity dates.

There is a clock attack which can brick many GPS receivers. GPS time uses a "week number", which is only 10 bits. Every 1024 weeks, GPS time wraps around. The first rollover was on 1999-08-15, and the next rollover is 2019-05-06. So standalone GPS receivers (not phones; they're "assisted GPS" and have to talk to a server) store a value indicating which rollover period they are currently in.

Sending phony signals to a GPS receiver which gradually advance the time can, for some units, convince it to advance the rollover period number in nonvolatile memory. On some devices, no way to reset it at all. Once this has happened, the ephemeris data won't be used properly, and it can't produce valid location data.

OpenNTPD has implemented a clever mitigation to this problem. It relies on trusting various key sites such as Google. You put one or more lines like this into your configuration file:

   constraints from "https://www.google.com/search?q=openntpd"

As the man page puts it:

   ntpd(8) can be configured to query the `Date'
   from trusted HTTPS servers via TLS. This time
   information is not used for precision but
   acts as an authenticated constraint, thereby
   reducing the impact of unauthenticated NTP
   `Man-In-The-Middle' attacks. Received NTP
   packets with time information falling outside
   of a range near the constraint will be
   discarded and such NTP servers will be
   marked as invalid. 

Of course, the devil is in the details. IIRC at the moment this check is only made when NTPD starts up, and not periodically during operation. But the general idea is probably quite solid.

One can always use GPSD http://www.catb.org/gpsd/gpsd-time-service-howto.html

Not mentioned in the paper's implications section, so I'll ask, is there also a significant "bootstrapping" class of attacks on services where special access is granted to the earliest created account? Eg. Wordpress-like systems without a hardcoded admin username, and an installation process that asks the 'first' client to set the administrator credentials.

Could the OS default to not allowing time to be set over NTP to anything before a certain hardcoded date?

OS updates could increase this hardcoded date, and the user could still override it if they wanted.