xenial (1) tlsdate.1.gz

Provided by: tlsdate_0.0.7-1.1ubuntu1_amd64 bug

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 communication 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 trustworthy. 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: 'www.ptb.de')

       -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-readable 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. Commonly, 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
              certificates 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 still in Alpha, and may not work as expected.

AUTHOR

       Jacob Appelbaum <jacob at appelbaum dot net>

SEE ALSO

       tlsdated(1), tlsdate-helper(1) tlsdate-routeup(1) tlsdate-dbus-announce(1)