full-disclosure - Windows Time Synchronization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: michealespinola at gmail.com (Micheal Espinola Jr)
Subject: Windows Time Synchronization - Best Practices

You can certainly have multiple time servers specified with Windows
Time Service (SNTP).  RTM.  It has the ability to failover through a
list.

If you need the full features of NTP, by all means use a third party
daemon.  However, in keeping my routers, RADIUS, and Kerberos sync'd
properly -  I have yet to require anything that SNTP is unable to
provide.

I've never heard of time.microsoft.com, and have never seen any
indication in any documentation to ever suggest using it.  MS's docs
have always suggested US naval observatory sites (since the
documentation is US-based).

I missed something.  Why would the requester time sync to Seattle, WA
USA if they are in Brazil?  That certainly goes against NTP RFC's,
regardless of any suggestions of the use of time.microsoft.com.

I have used 3rd party daemons as well as the built-in SNTP.  Both work
equally well.  The built-in tools can work just fine if you understand
the components and know how to properly use them.  There  is more
functionality available than what is simply represented by NET TIME.
Again, its a matter of RTM.



On Thu, 21 Oct 2004 14:47:25 -0700 (PDT), Gary E. Miller <gem@...lim.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Yo David!
> 
> On Thu, 21 Oct 2004, Cushing, David wrote:
> 
> > > In my experience NTP will work a lot better for
> > > you than Windows Time server.
> >
> > Windows time service uses SNTP.
> 
> SNTP is RFC 2030, It says:
> 
>   "SNTP can be used when the ultimate performance of the full
>   NTP implementation described in RFC-1305 is not needed or justified."
> 
> So right off the bat you know you are sacrificing something.  Why settle
> for less than the best when the best is free?
> 
> RFC 2030 Continues:
> 
>   "It is strongly recommended that SNTP be used only at the extremities
>   of the synchronization subnet. SNTP clients should operate only at
>   the leaves (highest stratum) of the subnet and ..."
> 
>   "The full degree of reliability ordinarily expected of primary servers
>   is possible only using the redundant sources, diverse subnet paths
>   and crafted algorithms of a full NTP implementation. "
> 
> Seems to me that rules out using it to connect to the stratum 1 in
> Seattle, WA from Brazil.
> 
> > > The protocol is robust and you are not dependent on the
> > > single point of failure called: time.microsoft.com.
> >
> > Never heard of time.microsoft.com being down or incorrect.
> 
> Me neither, but it has been unreachable.  Since the original requestor
> was from Brazil I would think that reachability would be an issue
> for him.  Last time I was monitoring reachability to Brazil there
> were often outages and bottlenecks to there from the US.
> 
> > You can use 'net time' or regedit to change it.
> >
> > http://www.microsoft.com/windows2000/docs/wintimeserv.doc
> 
> Yeah, but you are still stuck with only ONE server, you are stuck with
> SNTP and you have almost no way to tell if the time daemon is doing the
> right thing.
> 
> With NTP you can designate a local master that gets it's time from a
> diverse set of sources.  It is easy to verify and monitor it's proper
> functioning.  Then you can redistribute it to your local hosts.
> 
> Contrary to what some may believe, accurate time is very important to
> security.
> 
> One time keys, like S/Key, depend on accurate time for their functioning.
> 
> Any stronge encryption scheme, like IPSec, needs a good clock at both
> ends to default antireplay attacks
> 
> When debugging a major system crash, involving many routers, switches,
> hosts, etc. it is important to have well synced clocks to determine
> first failure.
> 
> Stick exchanges require members to use accurate clocks to help prevent
> fraud.
> 
> Etc...
> 
> RGDS
> GARY
> - ---------------------------------------------------------------------------
> Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
>        gem@...lim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQFBeC5w8KZibdeR3qURAjDhAJ9kue1cKLMrcVykpL4P03XyCnuB+ACbBL4b
> mNs+1jkUA470nRGx6ZXPGGA=
> =9SAK
> -----END PGP SIGNATURE-----
> 
> 
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 


-- 
Micheal