Manual Reference Pages - TCPCRYPTD (8)
B]tcpcryptd] - Implement the tcpcrypt protocol by transparently
modifying network I/O
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 B]tcpcryptd].
The daemon receives packets for transformation via a "divert port",
configurable with B]-p] I]port].
The daemon communicates with user programs via a "control socket",
configurable with B]-u] I]socket_address].
If I]socket_address] begins with "/", it is interpreted as a
filesystem path pointing to a unix-domain socket; if it is of the form
":I]port]", it is interpreted as the internet address
Verbosity may be increased with multiple B]-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[aq] server), but may be redirected to another test-server with
B]-s] I]hostname] or disabled completely with B]-f].
The B]tcpcryptd] daemon transforms TCP segments via a kernel
"divert" port in order to implement "opportunistic encryption" according
to the I]tcpcrypt] protocol.
For a peer that signals in the connection handshake that it has support
for the I]tcpcrypt] protocol, ephemeral keys are exchanged and
used to protect the confidentiality and integrity of the
connection[aq]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
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
The I]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 I]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
A I]session id] is derived from the ephemeral keys used to encrypt
each connection protected by I]tcpcrypt].
This identifier is (probabalistically) unique over all connections, is
not secret, and may be extracted by applications via the user library
Session ids for all active connections may also be listed with the
netstat-like utility B]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 I]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.
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.