Nmap Development mailing list archives
Re: [NSE] False timestamp in ssl-date
From: nnposter () users sourceforge net
Date: Fri, 22 Aug 2014 21:56:25 +0000
Daniel Miller wrote:
1. How did you decide on 3 seconds for max allowed jitter? This value should be chosen to be a small number that is larger than the variance we would see in half of one round trip. 3 seconds sounds pretty good, given that we set a socket timeout of 5 seconds, but maybe we should be more lenient? Given that we allow a 3-minute window (90 seconds each way) before we even apply this second test, we can probably allow a wider range of values to allow for weird network conditions.
Yes, the idea was to align it roughly with the socket timeout. I have tweaked the code a little to make it dead-obvious. (See the small follow-up patch below.) P.S. The quick-success window is actually 3 hours, which reflects Fyodor's earlier suggestion. My original choice of +/-5 minutes was based on the Kerberos tolerance. There is really no obvious correct choice. It is a trade-off between false positives and the script speed (and traffic volume). --- scripts/ssl-date.nse.orig 2014-08-18 16:00:12.868142500 -0600 +++ scripts/ssl-date.nse 2014-08-22 15:44:30.962451100 -0600 @@ -43,10 +43,13 @@ end -- Miscellaneous script-wide constants +local conn_timeout = 5 -- connection timeout (seconds) local max_clock_skew = 90*60 -- maximum acceptable difference between target -- and scanner clocks to avoid additional - -- testing -local max_clock_jitter = 3 -- maximum acceptable target clock jitter + -- testing (seconds) +local max_clock_jitter = 5 -- maximum acceptable target clock jitter + -- Logically should be 50-100% of conn_timeout + -- (seconds) local detail_debug = 2 -- debug level for printing detailed steps @@ -81,7 +84,7 @@ if not specialized_function then sock = nmap.new_socket() - sock:set_timeout(5000) + sock:set_timeout(1000 * conn_timeout) status, err = sock:connect(host, port) if not status then sock:close()
2. When we determine that the randomness does not represent time, should we report this as a legitimate result, not as an error (with stdnse.format_output)? I think people may be interested in that as a datapoint, since it could be used to fingerprint SSL implementations.
This may be the case but I was not ready to introduce changes to the output because I do not have a good feel if it would cause issues to downstream consumers of the data. In the follow-up patch below I am not returning any structured data, only populating the output attribute with "TLS randomness does not represent time". If anybody has different ideas, such as having explicit element <elem key="timesource">true/false</elem>, then please do let me know. --- scripts/ssl-date.nse.orig 2014-08-18 16:00:12.868142500 -0600 +++ scripts/ssl-date.nse 2014-08-22 15:44:30.962451100 -0600 @@ -208,7 +211,7 @@ return stdnse.format_output(false, "Unable to obtain data from the target") end if status ~= result.ACCEPTED then - return stdnse.format_output(false, "TLS randomness does not represent time") + return {}, "TLS randomness does not represent time" end end Cheers, nnposter _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- [NSE] False timestamp in ssl-date nnposter (Aug 01)
- Re: [NSE] False timestamp in ssl-date Daniel Miller (Aug 01)
- Re: [NSE] False timestamp in ssl-date David Fifield (Aug 01)
- Re: [NSE] False timestamp in ssl-date nnposter (Aug 07)
- Re: [NSE] False timestamp in ssl-date nnposter (Aug 07)
- Re: [NSE] False timestamp in ssl-date Fyodor (Aug 16)
- Re: [NSE] False timestamp in ssl-date nnposter (Aug 18)
- Re: [NSE] False timestamp in ssl-date Daniel Miller (Aug 20)
- Re: [NSE] False timestamp in ssl-date nnposter (Aug 22)
- Re: [NSE] False timestamp in ssl-date nnposter (Aug 07)