
New attacks on Network Time Protocol can defeat HTTPS and create chaos - alwillis
http://arstechnica.com/security/2015/10/new-attacks-on-network-time-protocol-can-defeat-https-and-create-chaos/
======
Animats
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.

------
PhantomGremlin
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.

~~~
mlichvar
The problem with this solution is that it's very expensive. Imagine couple
hundreds of millions of computers making a TLS connection every few minutes.

For NTP there is Autokey (RFC 5906), which allows authentication of the
servers with public-key crypto. It has various problems, one of them is that
it's insecure.

The NTP working group is currently preparing a Network Time Security
specification and its implementation in NTP, which is supposed to replace
Autokey.

[https://datatracker.ietf.org/wg/ntp/documents/](https://datatracker.ietf.org/wg/ntp/documents/)

------
ommunist
One can always use GPSD [http://www.catb.org/gpsd/gpsd-time-service-
howto.html](http://www.catb.org/gpsd/gpsd-time-service-howto.html)

------
gerard
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.

------
emmab
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.

