Bug#783174: tlsdate: Time retrieved from default host (www.ptb.de) jumping all over the place?
On 4/27/15, Rian Hunter r...@thelig.ht wrote: Hi, This totally hosed all of my systems!! Sorry to hear that this issue has caused you problems. :( I think relying on the internal server_random member of the ssl data structure is error prone and to me it's not unexpected that a server would randomize the timestamp part of their random ssl seed. The erroroneous code is in src/tlsdate-helper.c line 1207. That isn't a bug - code upstream in other proejcts has changed since this was implemented. At the time of creating tlsdate, the TLS spec specifically that it must not be randomized but rather a time stamp. My suggestion is that instead of changing the default server, instead default to using the HTTP Date header. This header is intended to contain the current time. That's a nice thing to do but realistically - you need to pick a server that you trust. I achieved this by changing the DAEMON_OPTS in /etc/default/tlsdated DAEMON_OPTS=-- /usr/bin/tlsdate -w That is a fine way to set it, yes. You also have to change how DAEMON_ARGS is set in /etc/init.d/tlsdated. Add this line after the line that sourced /etc/default/tlsdated: [ -r /etc/default/$NAME ] . /etc/default/$NAME DAEMON_ARGS=-f /etc/tlsdate/tlsdated.conf $DAEMON_OPTS If you think there is a different bug, please open another bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783174: tlsdate: Time retrieved from default host (www.ptb.de) jumping all over the place?
Hi, This totally hosed all of my systems!! I think relying on the internal server_random member of the ssl data structure is error prone and to me it's not unexpected that a server would randomize the timestamp part of their random ssl seed. The erroroneous code is in src/tlsdate-helper.c line 1207. My suggestion is that instead of changing the default server, instead default to using the HTTP Date header. This header is intended to contain the current time. I achieved this by changing the DAEMON_OPTS in /etc/default/tlsdated DAEMON_OPTS=-- /usr/bin/tlsdate -w You also have to change how DAEMON_ARGS is set in /etc/init.d/tlsdated. Add this line after the line that sourced /etc/default/tlsdated: [ -r /etc/default/$NAME ] . /etc/default/$NAME DAEMON_ARGS=-f /etc/tlsdate/tlsdated.conf $DAEMON_OPTS Thanks, Rian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783174: tlsdate: Time retrieved from default host (www.ptb.de) jumping all over the place?
I think relying on the internal server_random member of the ssl data structure is error prone and to me it's not unexpected that a server would randomize the timestamp part of their random ssl seed. The erroroneous code is in src/tlsdate-helper.c line 1207. That isn't a bug - code upstream in other proejcts has changed since this was implemented. At the time of creating tlsdate, the TLS spec specifically that it must not be randomized but rather a time stamp. Yeah my bad, I was in a bit of a WTF-mood when I ran into this and I ignored that this is actually how tlsdate is supposed to work. I saw something called random being copied into something called timestamp and my WTF-meter went to 11. I understand that a silent interface change occurred. My suggestion is that instead of changing the default server, instead default to using the HTTP Date header. This header is intended to contain the current time. That's a nice thing to do but realistically - you need to pick a server that you trust. Yeah, trust is top of line, second is shared semantics. In this case I trusted www.ptb.de, we just had different ideas about how to interpret some bytes. I expect this will happen more and more. On the other hand, I expect the meaning of the Date: header to be more consistent across servers. So maybe the the most sane default is to tie it to a Debian-maintained server and use the Date header to defend against an accidentally incompatible SSL configuration. In the absence of an available Debian server in the short-to-medium term, I think -w would be an effective and easy-to-make change *today*. You also have to change how DAEMON_ARGS is set in /etc/init.d/tlsdated. Add this line after the line that sourced /etc/default/tlsdated: [ -r /etc/default/$NAME ] . /etc/default/$NAME DAEMON_ARGS=-f /etc/tlsdate/tlsdated.conf $DAEMON_OPTS If you think there is a different bug, please open another bug? Yeah this is a different little bug, I'll file. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783174: tlsdate: Time retrieved from default host (www.ptb.de) jumping all over the place?
Hi Sebastian,
On 4/23/15, Sebastian Pipping sebast...@pipping.org wrote:
Package: tlsdate
Version: 0.0.12-2~bpo70+1
Severity: normal
When using debian.org for a host, time is somewhat stable:
$ for i in {1..10}; do tlsdate --dont-set-clock --showtime -H debian.org ;
done
Thu Apr 23 13:06:59 CEST 2015
Thu Apr 23 13:06:58 CEST 2015
Thu Apr 23 13:06:58 CEST 2015
Thu Apr 23 13:06:59 CEST 2015
Thu Apr 23 13:07:00 CEST 2015
Thu Apr 23 13:07:01 CEST 2015
Thu Apr 23 13:07:03 CEST 2015
Thu Apr 23 13:07:01 CEST 2015
Thu Apr 23 13:07:02 CEST 2015
Thu Apr 23 13:07:03 CEST 2015
However, the default host www.ptb.de off pristine
/etc/tlsdate/tlsdated.conf
shows different behavior:
$ for i in {1..10}; do tlsdate --dont-set-clock --showtime -H www.ptb.de ;
done
| sed 's|CET|CET |'
Thu Jan 18 00:20:52 CET 1973
Sun Apr 22 21:45:01 CEST 2018
Thu Nov 25 03:42:48 CET 1971
Wed Oct 23 06:20:11 CEST 1996
Tue Jan 29 07:36:25 CET 2104
Wed Aug 2 08:54:05 CEST 2017
Sat Jan 13 03:44:29 CET 2046
Fri Jan 28 04:20:04 CET 2101
Sun Dec 27 03:11:09 CET 2105
Fri Feb 8 05:32:52 CET 2013
I am unsure if that's a bug in tlsdate or broken/compromised setup at
www.ptb.de. Any ideas?
ptb.de appears to be randomizing time stamps. I'm open to a new
default host for Debian or for upstream. Thoughts? A TLS enabled
debian.org host (which one?) could do the trick if it wouldn't upset
anyone.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783174: tlsdate: Time retrieved from default host (www.ptb.de) jumping all over the place?
Package: tlsdate
Version: 0.0.12-2~bpo70+1
Severity: normal
When using debian.org for a host, time is somewhat stable:
$ for i in {1..10}; do tlsdate --dont-set-clock --showtime -H debian.org ; done
Thu Apr 23 13:06:59 CEST 2015
Thu Apr 23 13:06:58 CEST 2015
Thu Apr 23 13:06:58 CEST 2015
Thu Apr 23 13:06:59 CEST 2015
Thu Apr 23 13:07:00 CEST 2015
Thu Apr 23 13:07:01 CEST 2015
Thu Apr 23 13:07:03 CEST 2015
Thu Apr 23 13:07:01 CEST 2015
Thu Apr 23 13:07:02 CEST 2015
Thu Apr 23 13:07:03 CEST 2015
However, the default host www.ptb.de off pristine /etc/tlsdate/tlsdated.conf
shows different behavior:
$ for i in {1..10}; do tlsdate --dont-set-clock --showtime -H www.ptb.de ; done
| sed 's|CET|CET |'
Thu Jan 18 00:20:52 CET 1973
Sun Apr 22 21:45:01 CEST 2018
Thu Nov 25 03:42:48 CET 1971
Wed Oct 23 06:20:11 CEST 1996
Tue Jan 29 07:36:25 CET 2104
Wed Aug 2 08:54:05 CEST 2017
Sat Jan 13 03:44:29 CET 2046
Fri Jan 28 04:20:04 CET 2101
Sun Dec 27 03:11:09 CET 2105
Fri Feb 8 05:32:52 CET 2013
I am unsure if that's a bug in tlsdate or broken/compromised setup at
www.ptb.de. Any ideas?
Best, Sebastian
-- System Information:
Debian Release: 7.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tlsdate depends on:
ii libc6 2.13-38+deb7u8
ii libevent-2.0-5 2.0.19-stable-3+deb7u1
ii libssl1.0.0 1.0.1e-2+deb7u16
tlsdate recommends no packages.
Versions of packages tlsdate suggests:
pn apparmor none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
