Compatibility
Published
Nothing about a TLS connection is expressed in the call. You call connect, and everything that decides whether the connection is safe lives in an object beside it: the minimum protocol version, the cipher list, the trust anchors, whether a client certificate is demanded, whether an unauthorised peer is refused. Those names belong to node, not to your codebase, and the handshake either sees them or it does not. A handshake that does not see them still succeeds.
What was measured
One file against node's own TLS stack, driven through five protection profiles for the base column and both member-renaming profiles for everything after. It stands up real servers on the loopback interface with a generated certificate pair and runs the five configurations that matter: a client that pins TLS 1.3 against a peer capped at 1.2, a server that demands a client certificate, a pinned cipher list with an ALPN protocol negotiated against a peer that prefers something weaker, an SNI callback that records the name the client sent, and one deliberately relaxed connection to an internal endpoint with a private certificate.
The base column is clean. On the default target, the modern target, the gate profile, the modern gate profile and the string-transform profile, every handshake reached the same verdict, negotiated the same cipher, and produced the same protocol version. Protecting a service that speaks TLS does not disturb TLS.
Everything below is the member-renaming column. Each verdict is read from the side of the connection that is entitled to it, which matters more here than anywhere else in this series. Under TLS 1.3 a client believes it is connected before the server has finished looking at its certificate, so the client's opinion of a mutual-TLS handshake is worthless. The server's opinion is printed instead.
A pinned TLS 1.3 client that quietly speaks 1.2
The first arm renamed the key that carries the minimum protocol version. Before, the pinned client refused the legacy peer outright and the run recorded a protocol version alert. After, the same client connected, and the line reads CONNECTED with TLS 1.2 beside it.
That is a protocol downgrade performed by a build step. The pin is still in the source, three lines above the call, spelled correctly. Node received an options object with no minimum version in it, applied its own default of TLS 1.2, and completed a handshake that the code was written to prevent.
It is worth being precise about why this is quiet. There is no error, no warning and no failed request. The connection works. Everything downstream of it works. The only difference is the protocol version, which nothing in an ordinary application ever asserts on, and which is exactly the thing the pin existed to control.
The cipher arm produced the same shape. A client pinned to a single strong suite was talking to a peer that offers two and prefers the weaker one. Renaming the cipher key handed the choice back to the peer's preference, and the negotiated suite moved from the 256-bit suite the client demanded to the 128-bit suite the peer wanted. Both are respectable ciphers, which is precisely why nobody would notice.
Two details make that arm more general than it looks. The peer in this measurement is deliberately configured to honour its own order rather than the client's, which is how most servers are configured and is the reason a client-side cipher list is written at all. And the list itself is a string, so it survives the build untouched; what is lost is only the property name that delivers it. The value is present, correct and unreachable, which is the exact signature of every finding in this series.
If your compliance posture includes a statement about minimum TLS versions or approved cipher suites, this is the arm to think about first. The statement is usually evidenced by pointing at the configuration, and the configuration is still there and still correct on both sides of the rename. What changed is whether node was asked.
Mutual TLS stops asking for the certificate
The sharpest result in this file came from the option that turns on client certificate authentication. The server was configured to request a certificate and to reject a client that cannot produce one. Before renaming, a client with no certificate at all was refused during the handshake and the server recorded the refusal.
After renaming that one key, the server recorded a session, and the peer certificate on it is empty. The line goes from a refusal to a session belonging to nobody.
That is an authentication control removed, on the server, by renaming a property in the server's own configuration. Mutual TLS is frequently the only thing standing between an internal service and anything that can route to it, and it is often chosen precisely because it does not depend on application code being correct. Here it was undone without touching application code at all.
Renaming the request-certificate key and the reject-unauthorised key together did both things at once: the anonymous client got its session, and, in the same run, the internal endpoint that deliberately relaxes verification stopped working. One pattern, two opposite outcomes, in the same file, in the same run. That combination is a good illustration of why a partial failure is so hard to read from the outside: the run produces a visible breakage and a silent weakening at the same time, and the visible one gets the attention.
It also has a practical consequence for how this gets caught. The team debugging the internal endpoint that suddenly refuses a self-signed certificate will find the cause quickly, fix it by excluding that one name from the pattern, and ship. The mutual-TLS server sitting quietly beside it, admitting anonymous clients, produces no ticket at all.
The one arm that fails closed, and the two that fail loudly
The relaxed connection is the useful contrast. One endpoint in the file connects to an internal box with a self-signed certificate and switches peer verification off to do it. That is the only option in the file that permits something rather than restricting it, and it is the only one whose failure is safe: renaming it restored the default, verification came back on, and the connection was refused with a self-signed certificate error.
That is the pattern this series keeps measuring, and it is worth stating as a rule. An option that restricts fails open when its name is lost, because the library's default is the permissive one. An option that permits fails closed. A codebase full of relaxations gets loud, immediate failures; a codebase full of hardening gets silence and ships.
Two arms fail loudly for a different reason. Renaming the trust-anchor key made every verification fail with a self-signed certificate error, because the certificate authority list simply is not there. Renaming the key and certificate pair broke the server's own identity, and the handshakes fail with a signature algorithm error before any application code runs. Those are the good outcomes: they stop the process on the first connection, in every environment, including the developer's.
The control arm renamed the fields of the file's own result object, the ones it writes and reads itself. Behaviour was identical, because both ends of that read moved together. That is what a self-owned name looks like, and it is the reason the arms above are attributable to node's names rather than to renaming in general.
ALPN and SNI: two names the peer never receives
Two arms in this file break a protocol without breaking a connection.
Renaming the ALPN key removed the protocol list from the client hello. The handshake succeeded and the negotiated protocol went from the application's own protocol name to none at all. A server that routes by ALPN now sees a client asking for nothing in particular, and will either fall back to a default protocol or hand the connection to the wrong handler. The connection is up either way.
Renaming the server-name key removed SNI. The server's own callback recorded that no name was sent, where before it recorded the hostname. On a host serving one certificate this changes nothing; on a host serving many, the server picks a default certificate, and the client validates whatever it is given against a hostname it no longer sent. The handshake in this measurement still succeeded, which is the point worth carrying away: the failure surfaces later, on a different host, in production.
Both arms share a property that makes them worse than an outright break. The peer receives a client hello that is entirely valid; it is simply the client hello of a different, less specific client. Nothing on either side has anything to report, and any diagnostic that captures the connection after the fact records a successful handshake. The information that would identify the problem, that the client asked for less than it was written to ask for, exists only in the milliseconds when the hello was assembled.
What to do about it
Protection alone did not change a single handshake on any of the five profiles measured, so nothing here argues against protecting a service that speaks TLS. Every result above required member renaming with a pattern broad enough to reach node's option names.
Keep the TLS vocabulary out of that pattern: minVersion, maxVersion, ciphers, ALPNProtocols, servername, ca, key, cert, requestCert, rejectUnauthorized, sigalgs, ecdhCurve and the SNI callback name. As everywhere else in this series, anchoring the pattern to a naming convention you own is stronger than maintaining a list of names to avoid, because the list grows whenever node adds an option.
Then assert on the connection rather than on the configuration. After a handshake, the socket will tell you the protocol version, the negotiated cipher, the ALPN protocol and whether the peer was authorised. One integration test that reads those four values catches every silent arm on this page, and it is the only kind of check that could: a test asserting that the options object contains a minimum version will pass forever, on both sides of the rename.
If you run mutual TLS, add the server-side assertion too. Connect once with no client certificate and require the attempt to fail. That test is three lines, it exercises the control rather than the configuration, and it is the difference between an authentication requirement and a comment.
Frequently asked questions
Does obfuscation break TLS connections?
Not in the default configuration. A file that pins a protocol version, runs mutual TLS, negotiates ALPN and sends SNI produced identical handshakes, ciphers and verdicts on all five protection profiles measured. TLS options become a surface only when member renaming is enabled and the pattern reaches the option names node reads.
Can member renaming downgrade a TLS connection?
Yes, and it was measured directly. With the minimum-version key renamed, a client pinned to TLS 1.3 connected to a peer capped at TLS 1.2 instead of refusing it. Node received no minimum version, applied its default, and completed the handshake. There is no error and the pin is still present in the source.
What happens to mutual TLS after member renaming?
The server stops asking. With the request-certificate key renamed, a client presenting no certificate at all was given a session, where the same client had previously been refused during the handshake. The verdict was read on the server, because under TLS 1.3 a client believes it is connected before the server has evaluated its certificate.
Why do some TLS options fail loudly and others silently?
It depends on whether your option restricts or permits. Restrictive options such as a version pin or a cipher list fail open, because the library's default is the permissive one. The one relaxation in the measurement, switching off peer verification for an internal endpoint, failed closed: verification came back on and the connection was refused.
Do ALPN and SNI survive member renaming?
No, and neither failure stops the connection. Renaming the ALPN key removed the protocol list from the client hello and the negotiated protocol became none. Renaming the server-name key removed SNI, and the server's callback recorded that no name had been sent. Both handshakes still succeeded.
Which TLS option names should stay out of a rename pattern?
minVersion, maxVersion, ciphers, sigalgs, ecdhCurve, ALPNProtocols, servername, ca, key, cert, pfx, passphrase, requestCert, rejectUnauthorized and the SNI callback name. Anchoring the pattern to your own naming convention is more durable than the list, which grows with every node release.
How do we test TLS configuration on a protected build?
Read the connection, not the options. After the handshake, assert on the negotiated protocol version, the cipher name, the ALPN protocol and the authorised flag. For mutual TLS, add a test that connects without a client certificate and requires the attempt to fail. Those checks were the only ones in this measurement that could see anything had changed.
Related reading