NAME

       tcpcryptd - Implement the tcpcrypt protocol by transparently modifying network I/O

SYNOPSIS

       tcpcryptd [options]

OPTIONS

       A list of all options is produced by:

              tcpcryptd -h

       Configuration  of packet-diversion rules allows the system administrator to control which TCP connections
       are protected by tcpcryptd.  The  daemon  receives  packets  for  transformation  via  a  "divert  port",
       configurable with -p port.

       The  daemon  communicates with user programs via a "control socket", configurable with -u socket_address.
       If socket_address begins with "/", it is interpreted as a  filesystem  path  pointing  to  a  unix-domain
       socket; if it is of the form ":port", it is interpreted as the internet address localhost:port.

       Verbosity may be increased with multiple -v options.

       A  "phone-home"  test  will  be  performed  at  daemon startup to confirm end-to-end functionality of the
       implementation (by default, with the authors' server), but may be redirected to another test-server  with
       -s hostname or disabled completely with -f.

DESCRIPTION

       The  tcpcryptd  daemon  transforms  TCP  segments  via  a  kernel  "divert"  port  in  order to implement
       "opportunistic encryption" according to the tcpcrypt protocol.

       For a peer that signals in the connection handshake that  it  has  support  for  the  tcpcrypt  protocol,
       ephemeral  keys  are  exchanged and used to protect the confidentiality and integrity of the connection's
       application data.  (The protocol protects the integrity of parts of the TCP header as well.) When a  peer
       does  not  indicate  support  for  the  protocol,  the  daemon  will pass the remainder of the connection
       unperturbed (and thus unprotected).

       Application  software  need  not  be  modified  to  take  advantage  of  this  facility,  which  provides
       confidentiality  in  the  face  of  passive  network  attackers  (those who cannot modify network data in
       transit).   But  in  order  to  protect  communication  from  active  attackers,  the  application   must
       intentionally authenticate the connection as described below.

   Authentication
       The  tcpcrypt  protocol does not itself protect communications against "active attackers", that is, those
       who are able to modify network packets in transit.  Such an attacker may perform a "man  in  the  middle"
       attack  that  allows  her  to  behave as the endpoint of the encrypted connection and thus compromise its
       security.

       However, applications aware of tcpcrypt may authenticate the connection in whatever manner  they  choose,
       aided  by  an  identifier  for  the  connection  that  is derived from the protocol and made available by
       tcpcryptd:

       A session id is derived from the ephemeral keys used to encrypt each connection  protected  by  tcpcrypt.
       This  identifier  is (probabalistically) unique over all connections, is not secret, and may be extracted
       by applications via the user library libtcpcrypt.  Session ids for all active  connections  may  also  be
       listed with the netstat-like utility tcnetstat(8).

       Connection peers may ensure they are communicating securely with each other (enjoying confidentiality and
       integrity in the face of active network attackers) by confirming that the tcpcrypt session ids derived at
       each  end are identical.  For example, they may bind the session id together with a shared secret such as
       a password, sign it with public keys, use a voice connection to speak a  fingerprint  of  it,  or  simply
       record it for later confirmation.

SEE ALSO

       tcnetstat(8), <http://tcpcrypt.org/>

                                                                                                    tcpcryptd(8)