NAME¶
tcpcryptd - Implement the tcpcrypt protocol by transparently modifying
network I/O
SYNOPSIS¶
tcpcryptd [
options]
OPTIONS¶
A list of all options is produced by:
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/>