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