tlsdate man page on DragonFly

Man page or keyword search:  
man Server   44335 pages
apropos Keyword Search (all sections)
Output format
DragonFly logo
[printable version]

TLSDATE(1)			 User Manuals			    TLSDATE(1)

NAME
       tlsdate - secure parasitic rdate replacement

SYNOPSIS
       tlsdate	   [-hnvVstlw]	   [-H	  [hostname]]	 [-p	[port]]	   [-P
       [sslv23|sslv3|tlsv1]]	[--certdir    [dirname]]     [-x     [--proxy]
       proxy-type://proxyhost:proxyport]

DESCRIPTION
       tlsdate is a tool for setting the system clock by hand or by communica‐
       tion with the network. It does not set  the  Real  Time	Clock.	It  is
       designed	 to  be as secure as TLS (RFC 2246) but of course the security
       of TLS is often reduced to whichever CA racket you believe is trustwor‐
       thy.  By	 default,  tlsdate trusts your local CA root store - so any of
       these companies could assist in a MITM attack against you and you'd  be
       screwed.

       This  tool is designed to be run by hand or as a system daemon. It must
       be run as root or otherwise have the proper caps; it will not  be  able
       to  set	the  system time without running as root or another privileged
       user.

OPTIONS
       -h | --help
	      Print the help message

       -s | --skip-verification
	      Skip certificate verification

       -H | --host [hostname|ip]
	      Set remote hostname (default: 'google.com')

       -n | --dont-set-clock
	      Do not set the system clock to the time of the remote server

       -p | --port [port]
	      Set remote port (default: '443')

       -P | --protocol [sslv23|sslv3|tlsv1]
	      Set protocol to use when	communicating  with  server  (default:
	      'tlsv1')

       -C | --certdir [dirname]
	      Set the local directory where certificates are located (default:
	      '/etc/ssl/certs') This allows  for  certificate  or  certificate
	      authority (CA) pinning. To ensure that signatures are only valid
	      if they are signed by a specific CA or certificate, set the path
	      to a directory containing only the desired certificates.

       -x | --proxy [proxy-type://proxyhost:proxyport]
	      The  proxy argument expects HTTP, SOCKS4A or SOCKS5 formatted as
	      followed:

	       http://127.0.0.1:8118
	       socks4a://127.0.0.1:9050
	       socks5://127.0.0.1:9050

	      The proxy support should not leak DNS requests and  is  suitable
	      for use with Tor.

       -v | --verbose
	      Provide verbose output

       -V | --showtime [human|raw]
	      Show  the time retrieved from the remote server in a human-read‐
	      able format or as a raw time_t.

       -t | --timewarp
	      If the local clock is before  RECENT_COMPILE_DATE;  we  set  the
	      clock  to	 the  RECENT_COMPILE_DATE. If the local clock is after
	      RECENT_COMPILE_DATE, we leave the clock alone. Clock setting  is
	      performed	 as  the  first	 operation and will impact certificate
	      verification. Specifically, this option is helpful if  on	 first
	      boot, the local system clock is set back to the era of Disco and
	      Terrible	    Hair.      This	 should	     ensure	  that
	      X509_V_ERR_CERT_NOT_YET_VALID or X509_V_ERR_CERT_HAS_EXPIRED are
	      not encountered because of a broken RTC or the lack of  a	 local
	      RTC;  we	assume	that tlsdate is recompiled yearly and that all
	      certificates are otherwise considered valid.

       -l | --leap
	      Normally, the passing of time or time yet to come	 ensures  that
	      SSL  verify  functions  will fail to validate certificates. Com‐
	      monly,		 X509_V_ERR_CERT_NOT_YET_VALID		   and
	      X509_V_ERR_CERT_HAS_EXPIRED  are	painfully  annoying  but still
	      very important error states. When the only issue with  the  cer‐
	      tificates	 in  question  is  the timing information, this option
	      allows you to trust the remote system's time, as long as	it  is
	      after  RECENT_COMPILE_DATE  and  before MAX_REASONABLE_TIME. The
	      connection will only be trusted if X509_V_ERR_CERT_NOT_YET_VALID
	      and/or  X509_V_OKX509_V_ERR_CERT_HAS_EXPIRED are the only errors
	      encountered. The SSL verify function will not  return  X509_V_OK
	      if  there are any other issues, such as self-signed certificates
	      or if the user pins to a CA that	is  not	 used  by  the	remote
	      server. This is useful if your RTC is broken on boot and you are
	      unable to use DNSEC until you've at least had some kind of  leap
	      of cryptographically assured data.

       -w | --http
	      Run  in  web  mode:  look	 for the time in an HTTP "Date" header
	      inside an HTTPS connection, rather than in  the  TLS  connection
	      itself.  The provided hostname and port must support HTTPS.

BUGS
       It's likely! Let us know by contacting jacob@appelbaum.net

       Note that tlsdate(1) is in Beta, and may not work as expected.

AUTHOR
       Jacob Appelbaum <jacob at appelbaum dot net>

SEE ALSO
       tlsdate(1), tlsdate-helper(1), tlsdated(8), tlsdated.conf(5)

Linux				 OCTOBER 2012			    TLSDATE(1)
[top]

List of man pages available for DragonFly

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net