Re: [NSE] False timestamp in ssl-date

[nnposter () users sourceforge net]

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/