Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

tls: native pipe / splice between TLS and another native stream or fd

Ouverte
  • Quelque chose ne va pas ?
#63,957 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
30/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
javascript, node.js
Domaine
networking, security

Piste de recherche

Commencez par TLSWrap et le comportement existant de pipe/splice de net.Socket décrit dans l’issue, puis suivez le point d’entrée de la session tls.connect. Déterminez la conception et la sémantique de propriété pour le bridging des fd natifs avant l’implémentation. Le travail est considéré comme terminé lorsque le transfert duplex évite les handlers JavaScript par chunk, propage la contre-pression, préserve l’établissement de la session et respecte les critères indiqués de transfert et de benchmark.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

feature request
What is the problem this feature will solve?

net.Socket supports efficient kernel-level forwarding patterns (socket.pipe(), socket.pause()/resume() with native backpressure). There is no TLS equivalent — forwarding cleartext through TLSSocket always goes through the streams layer:

TCP (encrypted) → TLSWrap::ClearOut → JS Readable → user pump → JS Writable → sink
For full-duplex bridges (TLS ↔ TUN fd, TLS ↔ pipe, TLS ↔ another TCP socket), userland must:

  1. Implement two pumps (encrypt direction + decrypt direction) in JavaScript or duplicate logic in a native addon
  2. Manually coordinate backpressure (pause/resume, 'drain', TUN poll pause) across heterogeneous endpoints
  3. Absorb per-chunk copies and event-loop latency from TLSWrap (see related issues on SetImmediate deferral and read copies)

net has splice-style optimizations between fds; TLSWrap sits in the middle with no supported way to wire cleartext directly to a native sink/source while keeping session setup in Node.

This forces ecosystem projects (VPN helpers, transparent proxies, iOS tunnel tooling) to ship custom OpenSSL forwarders instead of composing built-in APIs.

What is the feature you are proposing to solve the problem?

Add native TLS pipe/splice primitives that pump cleartext between an established TLSSocket (or tls.connect session) and another native I/O endpoint without per-chunk JavaScript involvement.

Proposed API (sketch):

import tls from 'node:tls';
import net from 'node:net';
const tcp = await net.connect({ port });
const tlsSocket = await tls.connect({ socket: tcp, ... });
// Duplex: TLS cleartext ↔ numeric fd (TUN, pipe, etc.)
const handle = tlsSocket.spliceTo({
  fd: tunFd,
  direction: 'duplex',   // 'in' | 'out' | 'duplex'
});
handle.start();
await handle.stop();     // idempotent cleanup
// Or one-shot helper:
await tlsSocket.pipeToNative(tunFd, { direction: 'duplex' });

Implementation outline (on TLSWrap):

  1. Decrypt path (TLS → sink): SSL_read loop → write cleartext to sink fd; on EAGAIN/EWOULDBLOCK, pause uv_read_start on the underlying TCP stream until sink is writable (native backpressure, not socket.pause() in JS).
  2. Encrypt path (source → TLS): read cleartext from source fd → SSL_write → EncOut → TCP; stall source read when SSL_write or TCP send buffer is full.
  3. Reuse existing TLSWrap session, handshake, cert/PSK options — only the payload pump is native.
  4. Clear ownership semantics for fds (caller retains TUN; bridge does not close unless autoClose: true).

Relation to other proposals:

  • Lighter-weight than full tls.createBridge() when one side is already a TLSSocket and the other is an fd.
  • Complements zero-copy onread for users who still want one direction in JS.

Success criteria:

  • Bidirectional MTU-sized forwarding without socket.on('data') handlers.
  • Backpressure propagates correctly (no unbounded buffering in pending_cleartext_input_ / userland).
  • Benchmark shows lower CPU and event-loop utilization vs. an equivalent JS pump.
What alternatives have you considered?
  1. socket.pipe(otherSocket) through TLSSocket — Still routes every byte through JS streams; does not splice to raw fds; no TLS-aware backpressure.
  2. duplex streams + pipeline() — Same V8-boundary and allocation costs; popular but not a performance solution.
  3. tls.createBridge() (separate proposal) — Higher-level API that may subsume this for fd targets; spliceTo is a narrower addition for users who already have a TLSSocket and want fd bridging only.
  4. Custom N-API OpenSSL forwarder — Proven in production (e.g. iOS tunnel addons) but duplicates TLSWrap and OpenSSL linkage in every consumer.
  5. node:child_process + socat/openssl s_client — Operational hack, not embeddable in Node apps.
  6. Document manual pump patterns only — Insufficient; the gap is missing native wiring in TLSWrap, not developer skill.
Langage dominant
JavaScript
Étoiles
122k
Forks
39k
Merge moyen
3 j 22 h
PR mergées (30 j)
244

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de nodejs/node

Toutes les issues de nodejs/node

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.