1tcpcryptd(8) tcpcryptd(8)
2
6 tcpcryptd - Implement the tcpcrypt protocol by transparently modifying
7 network I/O
8
10 tcpcryptd [options]
11
13 A list of all options is produced by:
14 tcpcryptd -h
16 Configuration of packet-diversion rules allows the system administrator
18 to control which TCP connections are protected by tcpcryptd. The dae‐
19 mon receives packets for transformation via a "divert port", config‐
20 urable with -p port.
21 The daemon communicates with user programs via a "control socket", con‐
23 figurable with -u socket_address. If socket_address begins with "/",
24 it is interpreted as a filesystem path pointing to a unix-domain
25 socket; if it is of the form ":port", it is interpreted as the internet
26 address localhost:port.
27 Verbosity may be increased with multiple -v options.
29 A "phone-home" test will be performed at daemon startup to confirm
31 end-to-end functionality of the implementation (by default, with the
32 authors' server), but may be redirected to another test-server with -s
33 hostname or disabled completely with -f.
34
36 The tcpcryptd daemon transforms TCP segments via a kernel "divert" port
37 in order to implement "opportunistic encryption" according to the
38 tcpcrypt protocol.
39 For a peer that signals in the connection handshake that it has support
41 for the tcpcrypt protocol, ephemeral keys are exchanged and used to
42 protect the confidentiality and integrity of the connection's applica‐
43 tion data. (The protocol protects the integrity of parts of the TCP
44 header as well.) When a peer does not indicate support for the proto‐
45 col, the daemon will pass the remainder of the connection unperturbed
46 (and thus unprotected).
47 Application software need not be modified to take advantage of this
49 facility, which provides confidentiality in the face of passive network
50 attackers (those who cannot modify network data in transit). But in
51 order to protect communication from active attackers, the application
52 must intentionally authenticate the connection as described below.
53 Authentication
55 The tcpcrypt protocol does not itself protect communications against
56 "active attackers", that is, those who are able to modify network pack‐
57 ets in transit. Such an attacker may perform a "man in the middle"
58 attack that allows her to behave as the endpoint of the encrypted con‐
59 nection and thus compromise its security.
60 However, applications aware of tcpcrypt may authenticate the connection
62 in whatever manner they choose, aided by an identifier for the connec‐
63 tion that is derived from the protocol and made available by tcpcryptd:
64 A session id is derived from the ephemeral keys used to encrypt each
66 connection protected by tcpcrypt. This identifier is (probabalisti‐
67 cally) unique over all connections, is not secret, and may be extracted
68 by applications via the user library libtcpcrypt. Session ids for all
69 active connections may also be listed with the netstat-like utility
70 tcnetstat(8).
71 Connection peers may ensure they are communicating securely with each
73 other (enjoying confidentiality and integrity in the face of active
74 network attackers) by confirming that the tcpcrypt session ids derived
75 at each end are identical. For example, they may bind the session id
76 together with a shared secret such as a password, sign it with public
77 keys, use a voice connection to speak a fingerprint of it, or simply
78 record it for later confirmation.
79
81 tcnetstat(8), <http://tcpcrypt.org/>
82 tcpcryptd(8)