tcpcryptd(8)

💖 tcpcryptd 💖

okay bestie, welcome to tcpcryptd, section 8 of the manuals — aka the daemon that does the tcpcrypt protocol by transparently modifying network I/O ✨ no cap, it really does just reach in and rewrite your packets. sit down, grab a strawberry 🍓, and let's get into it.

---

✨ NAME ✨

tcpcryptd — implement the tcpcrypt protocol by transparently modifying network I/O 🦋

---

🌸 SYNOPSIS 🌸

tcpcryptd [options]

that's it. that's the whole vibe. she takes options and she goes 💅

---

🎀 OPTIONS 🎀

so you wanna see every option? iconic, love that for you:

tcpcryptd -h

that prints the whole list, periodt.

---

okay so here's the thing about packet-diversion rules: the system administrator gets to decide which TCP connections get protected by tcpcryptd. the daemon receives packets for transformation through a "divert port", and you configure that with -p port 👑

• -p port — sets the "divert port" that the daemon receives packets on for transformation.

---

the daemon also talks to user programs through a "control socket", and you configure that one with -u socket_address:

• -u socket_address — sets the "control socket" the daemon uses to communicate with user programs. if socket_address starts with "/", it's read as a filesystem path pointing to a unix-domain socket 🐧. if it's shaped like ":port", it's read as the internet address localhost:port 🌐.

---

• -v — bumps up verbosity. and the way that you can just stack them… multiple -v options = more verbose. obsessed 😌

---

and then there's the "phone-home" test 🫶 — it runs at daemon startup to confirm end-to-end functionality of the implementation (by default it calls up the authors' server), but you have options, bestie:

• -s hostname — redirects the "phone-home" test to another test-server at hostname.
• -f — disables the "phone-home" test completely. gone. not doing it. 💀

---

💜 DESCRIPTION 💜

the tcpcryptd daemon transforms TCP segments through a kernel "divert" port so it can implement "opportunistic encryption" according to the tcpcrypt protocol ✨

here's the tea: when a peer signals in the connection handshake that it supports the tcpcrypt protocol, ephemeral keys get exchanged and then used to protect the confidentiality and integrity of that connection's application data 🔐 (and yes, the protocol protects the integrity of parts of the TCP header too, she's thorough). but when a peer does not indicate support for the protocol, the daemon just passes the rest of the connection through unperturbed — and therefore unprotected 🙈

the best part?? your application software does not need to be modified to take advantage of this. it gives you confidentiality against passive network attackers — that's the ones who can't modify network data in transit. but to protect communication from active attackers, the application has to intentionally authenticate the connection, as described below 👇

---

🔥 Authentication 🔥

okay so real talk, this part is important and also a little scary, no cap.

the tcpcrypt protocol does not itself protect communications against "active attackers" — meaning the ones who are able to modify network packets in transit. an attacker like that can pull off a "man in the middle" attack that lets her behave as the endpoint of the encrypted connection and therefore compromise its security 😭 scary!! we don't love that!!

but!! applications that are aware of tcpcrypt can authenticate the connection however they want, and tcpcryptd helps by handing them an identifier for the connection that's derived from the protocol:

• a session id is derived from the ephemeral keys used to encrypt each connection protected by tcpcrypt. this identifier is (probabalistically) unique across all connections, it is not secret, and applications can extract it via the user library libtcpcrypt 📚. you can also just list the session ids for all active connections with the netstat-like utility tcnetstat(8) ⭐

so how do peers actually confirm they're talking securely to each other — enjoying confidentiality and integrity even with active network attackers around? by confirming that the tcpcrypt session ids derived at each end are identical 💖 for example, they might:

• bind the session id together with a shared secret, like a password 🔑
• sign it with public keys ✍️
• use a voice connection to speak a fingerprint of it 🎙️
• or simply record it for later confirmation 📝

any of those works. pick your fighter 🥊

---

🌈 SEE ALSO 🌈

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

---

psa bestie: this page is tcpcryptd(8) — that's the manual name, right there in the title and down in the footer too, so you always know which page you're in 💅

and that's the whole page, mwah 🎀 written up for the tcpcryptd(8) manual, dated and stamped with the version info in its footer, and honestly? she ate. go forth and encrypt opportunistically, you absolute main character 👑💖