TLS Server Interface Buf

[prettydiff]

Version

17.4.0

Platform

Windows 10

Subsystem

No response

What steps will reproduce the bug?

An insecure socket server is created as:

const connect = function (socket) {},
    server = net.createServer();
server.listen({
    port: 80
}, listener);
server.on("connection", connect);

A secure socket server is created as:

const connect = function (socket) {},
    server = tls.createServer({
        cert: "string",
        key: "string"
    }, connect);
server.listen({
    port: 443
}, listener);

The major difference is where I put the connect event handler for the "connection" event. I can execute a TLS server with the same pattern as the insecure server and the connect handler will fire, but the socket passed into the connect handler will never execute data events or error events. You can console.log that socket, but it is effectively mute. This is impossible to troubleshoot and no feedback is provided.

How often does it reproduce? Is there a required condition?

100%

What is the expected behavior?

There is a choice of resolutions:

1. Throw on assignment to the connection event of a TLS server, eg: server.on("connection", connect);
2. Fully support sockets created by an assigned connection handler.

What do you see instead?

Nothing. When this error is encountered I can see the handler for the connection event fire and I can console.log the socket passed into that handler, but all events assigned to that socket are ignored and there is no feedback of any kind. Problematic code example:

const connect = function (socket) {},
    server = tls.createServer();
server.listen({
    port: 80
}, listener);
server.on("connection", connect);

Additional information

No response

[bnoordhuis]

tls.Server is implemented on top of net.Server. The "connection" event is emitted by the latter, with a net.Socket as its argument.

It sounds like you're looking for the "secureConnection" event. It has the tls.Socket you're interested in.

[prettydiff]

Looking at the documentation I see both a connection and secureConnection as supported events on TLS.Server. Should the connection event be removed from the documentation if it doesn't work. Or better, should the connection event redirect to the secureConnection event?

[bnoordhuis]

I don't think so. The documentation for "connection" says (among other things) this:

This event can also be explicitly emitted by users to inject connections
into the TLS server. In that case, any Duplex stream can be passed.

That's valuable knowledge.

[prettydiff]

That is true, except the sockets generated in those connections are completely unusable and there is no messaging to that effect.

[bnoordhuis]

It also says this:

This event is emitted when a new TCP stream is established, before the TLS handshake begins. [..] Usually users will not want to access this event.

Seems clear enough to me but suggestions for improvement are of course welcome.

[prettydiff]

The problem is that its only clear after the fact. What I suspect is happening is this:

1. the connection event is inherited from the net library.
2. the connection handler receives a socket, because that is how the net library works.
3. the socket accepts events, such as data, exactly as document in the net library.
4. the socket never executes events because the later created secure socket receives all such events

This is undocumented behavior. It is unclear until after it is encountered and there is no communication about this behavior anywhere in either the documentation, error messaging, or stdout.

Perhaps passing null into the TLS connection event handler, instead of a socket, would suffice. I could possibly see a testing reason to determine if a TCP connection is made before the TLS handshake if you were wanting to test Node internals, but the socket passed into the handler has no value.

[bnoordhuis]

You're welcome to send a pull request that clarifies the documentation but anything that changes the runtime behavior is pretty much guaranteed to get shot down immediately.