[ntp:questions] SSL time request
mayer at ntp.org
Sun May 22 04:07:05 UTC 2011
On 5/21/2011 9:04 PM, Chris Albertson wrote:
> On Sat, May 21, 2011 at 3:18 PM, Danny Mayer <mayer at ntp.org> wrote:
>> On 5/19/2011 12:06 PM, Kevin Coulombe wrote:
>>> I'm looking into producing a 15 days demonstration version of an application
>>> for a client. I'm considering the use of an internet clock to validate this
>>> demo's duration, but a simple http request would be too easy to hack.
>>> Is there any way to request time in a secure manner such as an SSL
>>> connection. What I need is to validate that we are actually communicating
>>> with the "real" time server and that the message isn't tampered with.
>> The proper way to do this with NTP is to use the autokey protocol which
>> will authenticate the servers. Note that the basic way that NTP works is
>> to use 3 or more NTP servers which allows it to select only consistent
>> truechimers and that are close enough to each other timewise that it can
>> choose one of them to synch to. It is actually quite hard to tamper with
>> an NTP packet and have it not be noticed, mainly because it does not
>> rely on a single NTP server. Add autokey for each of the servers and
>> just about nothing can be tampered with.
>> Note that SSL is *not* secure when it comes to time since the SSL
>> certificate is in turn dependent on time. The autokey protocol deals
>> with that issue.
> Let me add one more thing. It should be obvious. You need to do the
> NTP protocol from within your program. Letting NTP sync the system
> time then using that is to easy to work around.
That does not make a lot of sense. Putting an NTP server into your own
code would be an extremely difficult thing to do. If you cannot rely on
NTP setting and disciplining your system clock and using the system time
then you have much bigger problems that accurate time.
> But a simpler method is to use SSL to "tunnel" to your server and use
> something very simple like the "time" protocol. NTP will give time to
> the milisecond level but the time protocol is faster and good enough
> for a second or so, more than you need.
As I said before SSL depends on accurate time in the first place so you
cannot use it for verifying time. In addition what you would need to do
requires TCP and adds a lot of variable delay which you not be able to
measure. The only thing you can do with a time protocol is to set the
clock. It cannot discipline the clock and ignore bad time.
> None of this will work if the person trying to break it knows about
> software, he'd just binary patch your software with an unconditional
Having access to the source code is unlikely unless it is publicly
available which is rather unlikely and if the attacker can get in to
patch the software then you have bigger problems than the software or
time. This all sounds like a solution looking for a problem.
More information about the questions