Misbehaving server

[Seth Terashima]

The attached JSON chain (in the format used by Google's golang client) shows the tictock.mixmin.net server clock going from July 6 to July 4.

The parsed log summary is below; first column is the public key. The ticktock server is listed in https://github.com/cloudflare/roughtime/blob/master/ecosystem.json. I emailed Steve on July 9 but haven't gotten a response.

I have no reason to suspect malice, but thought it'd be fun to share what is, to my knowledge, the first "in the wild" proof of a misbehaving server.

Seth

./clockchain-parser report.json 

2019/07/08 20:01:32 Loaded chain with 10 links

723f06b22365464aa20c494078d312041330ac0975e6160f817e74f86597fe50    2019-07-06 11:20:50 -0700 PDT  1000000

803eb78528f749c4bec2e39e1abb9b5e5ab7e4dd5ce4b6f2fd2f93ecc3538f1a    2019-07-06 11:20:50 -0700 PDT  1000000

6db4fe44f4bbcca5fac3bd6cb0f89bce6c16a94f5f7d1579a23d8eadeb129a11    2019-07-06 11:20:50 -0700 PDT  1000000

016e6e0284d24c37c6e4d7d8d5b4e1d3c1949ceaa545bf875616c9dce0c9bec1    2019-07-06 11:20:51 -0700 PDT  1000000

7ad3da688c5c04c635a14786a70bcf30224cc25455371bf9d4a2bfb64b682534    2019-07-06 11:20:51 -0700 PDT  1000000

723f06b22365464aa20c494078d312041330ac0975e6160f817e74f86597fe50    2019-07-04 08:30:13 -0700 PDT  1000000

803eb78528f749c4bec2e39e1abb9b5e5ab7e4dd5ce4b6f2fd2f93ecc3538f1a    2019-07-06 11:25:51 -0700 PDT  1000000

7ad3da688c5c04c635a14786a70bcf30224cc25455371bf9d4a2bfb64b682534    2019-07-06 11:25:51 -0700 PDT  1000000

6db4fe44f4bbcca5fac3bd6cb0f89bce6c16a94f5f7d1579a23d8eadeb129a11    2019-07-06 11:25:51 -0700 PDT  1000000

016e6e0284d24c37c6e4d7d8d5b4e1d3c1949ceaa545bf875616c9dce0c9bec1    2019-07-06 11:25:51 -0700 PDT  1000000

2019/07/08 20:01:32 Chain ok

[Christopher Patton]

Very cool, Seth!

[Steve Crook]

On 15/07/2019 18:36, Seth Terashima wrote:
> The attached JSON chain (in the format used by Google's golang client)
> shows the tictock.mixmin.net server clock going from July 6 to July 4.
>
> The parsed log summary is below; first column is the public key. The
> ticktock server is listed in
> https://github.com/cloudflare/roughtime/blob/master/ecosystem.json. I
> emailed Steve on July 9 but haven't gotten a response.
>
> I have no reason to suspect malice, but thought it'd be fun to share
> what is, to my knowledge, the first "in the wild" proof of a
> misbehaving server.

Hi Seth,

Nice catch! :)

There was nothing malicious about this but, you're right, it's good that
Roughtime caught it.  The server in question, ticktock.mixmin.net is
running on a Raspberry Pi with a GPS clock attached to it.  On July 6th,
I patched the OS and rebooted it. It uses NTP to set the system clock
from the GPS but, owing to a combination of issues (DNSSEC, NTP and the
lack of persistent hardware clock), NTP refused to adjust the time.  I
had to run "/usr/local/bin/ntpd -qg" to force it to accept the excessive
difference between system and ntp time.  Looking back at my log, I see:

-- Reboot --
Jul 04 15:29:24 ticktock kernel: Booting Linux on physical CPU 0xf00
Jul 04 15:29:24 ticktock kernel: Linux version 4.19.57-1-ARCH
(builduser@leming) (gcc version 8.3.0 (GCC)) #1 S>
Jul 04 15:29:24 ticktock kernel: CPU: ARMv7 Processor [410fc075]
revision 5 (ARMv7), cr=10c5387d
Jul 04 15:29:24 ticktock kernel: CPU: div instructions available:
patching division code
Jul 04 15:29:24 ticktock kernel: CPU: PIPT / VIPT nonaliasing data
cache, VIPT aliasing instruction cache
Jul 04 15:29:24 ticktock kernel: OF: fdt: Machine model: Raspberry Pi 2
Model B Rev 1.1

This appear to correspond with your entry:
723f06b22365464aa20c494078d312041330ac0975e6160f817e74f86597fe50
2019-07-04 08:30:13 -0700 PDT  1000000N

My lesson to learn from this is probably not to start the roughtime
server on reboot but to leave it down until the clock has adjusted to
the GPS and NTP is happy!

Cheers,
Steve