[Freedombox-discuss] Dev: New FreedomBox-Setup Dependency: NTP

[Daniel Kahn Gillmor]

On 12/11/2013 09:05 PM, intrigeri wrote:
> Bdale Garbee wrote (04 Dec 2013 18:29:24 GMT) :
>> At our meeting in Eben's offices in Feb, dkg came up with really cute
>> hack for setting the system time in an initial set-up script by
>> acquiring the client system's sense of time from I think an SSL session
>> initiation packet.  I'm not aware of that ever being publicly documented
>> or implemented in our stack, but it seemed like a really neat "hands
>> off" way to handle the set-the-time-on-first-boot problem without
>> relying on centralized infrastructure.
> 
> tlsdate (in Debian testing/sid) does just this. It is written by Jacob
> Appelbaum, who was on some FreedomBox technical board at some point
> IIRC. Sorry if it was mentioned already, I only read the list from
> time to time. I'm told that tlsdate has been installed by default on
> ChromeOS for a while (talking to Google servers, obviously).

The thing i wrote does the opposite thing from tlsdate.  tlsdate talks
to a TLS server and finds out what time the server thinks it is.

the hack i wrote was embedded in a web page and points the user to the
current host on a different port, but using https -- the browser tries
to load an <img> from this port, but the freedombox just listens for the
first part of the handshake from the browser and then closes the connection.

So it's using the user's browser's TLS stack to report the time to the
server so that we don't have to ask the user explicitly, or even be
connected to any public network at all to get an initial value for the
clock.

> Drawbacks are that 1. you have to trust the TLS server you're talking
> to to give you the right time (and getting the right time is
> especially important for a system that uses Tor); 2. the way tlsdate
> talks to the TLS server * the selection of TLS server(s) you are using
> is fingerprintable (but hiding the fact that "hey, this system is
> a FreedomBox" isn't part of the current threat model, is it?).

There's an even larger drawback to this approach (for both tlsdate and
the hack i threw together):

  http://datatracker.ietf.org/doc/draft-mathewson-no-gmtunixtime/
  https://www.ietf.org/mail-archive/web/tls/current/thrd2.html#10909

In particular, it looks like most TLS implementations (both client and
server) will be putting random data in the gmt_unix_time field in the
very near future.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20131212/0d69cb87/attachment.sig>