NAME

tlspool - A daemon program that concentrates TLS connectivity.

SYNOPSIS

tlspool [-k] [-c configfile]
tlspool [-p]

DESCRIPTION

The tlspool program runs as a local daemon that listens to a UNIX domain
socket where TLS can be requested for existing file descriptors.  It acts
as a central point for controlling TLS activities, including privileges
and certificate/key handling.  It implements TLS for TCP, and DTLS for
UDP and SCTP.

The tlspool functions as a TLS-application overlay over an industry-standard
PKCS #11 API over which key material can be looked up and used.  It will
select a local certificate and key based on a name provided by an application
program, and handle all authentication and, if so configured, authorization
as part of the TLS connection setup.

The tlspool will negotiate certificates in either X.509 or OpenPGP format,
with a preference for the latter.  It will perform validation by looking
up information online, rather than relying on a signature that some
authority once made to state that it (hopefully) performed a similar
validation just before creating the signature.  The complexity of verifying
such authorities and establishing if their certification signatures still
hold have grown to such a level of complexity that one might just as well
perform the validation live, at the time the information is useful.  Note
that this approach will only work for online processes.

The mechanisms supported to establish authenticity of a remote peer are
LDAP and DANE.  LDAP is available for domain and user certificates in
X.509 or OpenPGP format, DANE is only available for domain certificates
in X.509 format because it has not been defined for other applications.
LDAP connections themselves should be based on a DANE-protected server
certificate.

The remote information retrieved by the TLS Pool can slow down the
connection setup, and for that reason caching can be configured.  The
caching mechanism used is memcache, with a configurable timeout for
all data cached.  It is possible to bypass the cache for the most
sensitive operations.

TLS in itself is not overly private; the exchange of certificates
can be passively observed.  For this reason, the TLS Pool can implement
a more expensive and therefore optional two-phase approach, where a first
connection is setup under an anonymous Diffie-Hellman key exchange, and
immediately a secure re-negotiation is performed to exchange the actual
certificates.  This is possible if both client and server are willing to
accept an initial anonymous connection.  TODO:It will be seen as an error
when either party sends vital information over the anonymous connection yet.

When not called with the -p option, the TLS Pool daemon is started in the
background, optionally reading the file dictated by the -c option.  When
the -p option is present, a running TLS Pool daemon is assumed and a PIN
is requested on the terminal, and submitted to the daemon.  The -k option
is used to kill any already running daemon detected through the PID file,
instread of refusing to start a second daemon.



SEE ALSO

starttls_client
starttls_server
tlstunnel