Re: [NSE] False timestamp in ssl-date

[David Fifield <david () bamsoftware com>]

On Fri, Aug 01, 2014 at 09:13:25PM +0000, nnposter () users sourceforge net wrote:
> The current version of ssl-date.nse does not try to validate whether
> the TLS server randomness in fact represents time. Recent versions of
> OpenSSL are prominent examples where this is not true. It would be
> desirable to differentiate between target clocks that are simply off
> and cases where TLS does not give back the timestamp at all.
>
> The patch below changes the script behavior as follows:
>
> 1: Take a TLS time sample
> 2: (original version of the script simply reports the result and exits)
> 3: Compare it with the scanner clock
> 4: If the difference is less than 15 minutes then report the time and exit
> 5: Otherwise take a second TLS time sample
> 6: Compare it with the scanner clock
> 7: If the two differences from steps #3 and #6 are consistent (differ in
> less than 5 seconds) then report the time and exit
> 8: Otherwise fail the script
>
> It could be debated whether step #4 should be implemented but for me it
> was a compromise between accuracy and having to take the second sample
> every single time.

This is great. I think I would just always make two probes, and not base
the decision on a comparison to local time. If the server is generating
the field randomly, then the chances that two measurements differ by 10
or less is about 10/2^32 = 2.3e-09 = 2^-28.6, or 1 in 400 million. You
could always do three probes and make the probability negligible.

Maybe there are servers that don't use the time and don't generate
randomly, but do something else? Like a fixed value?

> +    if math.abs(origdelta - delta) > 5 then

I guess you can also reject if the second sample is less than the first.

David Fifield
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/