Skip to content

How to use new tls.TLSSocket(...) to establish a secure connection? #43994

Description

@armanbilge

Affected URL(s)

https://nodejs.org/docs/latest-v18.x/api/tls.html

Description of the problem

What is the correct, non-deprecated way to use the new tls.TLSSocket(...) constructor to establish a secure connection? Context: GHSA-2cpx-6pqp-wf35

According to two unmerged docs PRs, when directly calling new tls.TLSSocket(...) it is the user's responsibility to validate peer certificates and identity.

In #10846 it says:

Warning: When directly constructing a tls.TLSSocket instead of using
[tls.connect()][] it is the caller's responsibility to:

  • manage the lifetime of the the underlying socket, including connecting it;
  • validate the peer certificate and identity, see the ['secure'][] event.

Before using the connection, the user must make the following
checks or the connection should be considered completely insecure:

  1. Verify that the peer certificate is valid, see [ssl.verifyError()][].
  2. Verify that the peer certificate is for the expected host, see
    [tls.checkServerIdentity()][] and [tls.TLSSocket.getPeerCertificate()][].

In #23915 it says:

It is important to remember, however,
that it is the caller's responsibility to manage the lifecycle of the provided
net.Socket, including establishing the connection and validating peer
certificates and identity. See the ['secure'][] event.

And includes an example:

tlsSocket.on('secure', function() {
  const err = this.verifyError() ||
    tls.checkServerIdentity(hostname, this.getPeerCertificate());
  if (err)
    this.destroy(err);
});

Both PRs demonstrate how to do this validation, but require use of:

  1. The 'secure' event. In the current Node.js documentation, the only mention of 'secure' is under the deprecated tls.SecurePair, and is itself deprecated. It is also not clear that the 'secure' event is also emitted on tls.TLSSocket.
    https://nodejs.org/docs/latest-v18.x/api/tls.html#event-secure
  2. tlsSocket.ssl.verifyError(), which does not appear at all in the current documentation. Furthermore, according to TLSCallbacks => TLSWrap, better TLS inception #840 (comment) tlsSocket.ssl is a "legacy property".

Note that the described validation steps appear to be consistent with internal use

socket.on('secure', onServerSocketSecure);

node/lib/_tls_wrap.js

Lines 1044 to 1055 in 5fbf33e

function onServerSocketSecure() {
if (this._requestCert) {
const verifyError = this._handle.verifyError();
if (verifyError) {
this.authorizationError = verifyError.code;
if (this._rejectUnauthorized)
this.destroy();
} else {
this.authorized = true;
}
}

This leaves me with two concerns:

  1. The current documentation does not indicate that using new tls.TLSSocket(...) by itself does not result in a secure connection.
  2. As far as I can tell it is impossible to use new tls.TLSSocket(...) to establish a secure connection without relying on APIs that are undocumented, deprecated, and/or legacy.

Activity

  1. added
    docIssues and PRs related to Node.js documentation.
    on Jul 26, 2022
  2. added
    tlsIssues and PRs related to the tls subsystem.
    on Jul 26, 2022
  3. mcollina commented on Jul 26, 2022

    @mcollina
    SponsorMember

    @tniessen you might be able to help.

  4. AliMahmoudDev commented on Jun 6, 2026

    @AliMahmoudDev

    The short answer is that tls.connect() is the intended API for establishing secure connections — it handles certificate validation, the secureConnect event, and all the plumbing you described.

    If you need to use new tls.TLSSocket(socket) directly (e.g. upgrading an existing connection), the modern approach is:

    const tlsSocket = new tls.TLSSocket(socket, { ...options });
    
    tlsSocket.on("secureConnect", () => {
      if (!tlsSocket.authorized) {
        tlsSocket.destroy(tlsSocket.authorizationError);
        return;
      }
      // connection is ready
    });

    The secureConnect event is the non-deprecated replacement for the secure event. It fires once the TLS handshake completes. You then check tlsSocket.authorized (boolean) and tlsSocket.authorizationError (set when validation fails). The legacy tlsSocket.ssl.verifyError() is still available but undocumented for a reason — authorized/authorizationError is the public API.

    The two unmerged docs PRs you referenced are likely stale — secureConnect has been the standard event since at least Node 12.

  5. github-actions commented on Sep 5, 2026

    @github-actions
    Contributor

    This issue has been marked as stale due to 90 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  6. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Sep 5, 2026
  7. github-actions commented on Oct 5, 2026

    @github-actions
    Contributor

    This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
    If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    docIssues and PRs related to Node.js documentation.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.tlsIssues and PRs related to the tls subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions