Servername is not set on TLS sockets if there is a TLS client error

[pimterry]

• Version: v10.15.3
• Platform: Linux
• Subsystem: TLS

I am writing an HTTPS server and I want to try & detect when clients connect but reject my certificate. For irrelevant reasons this happens often.

If this happens, it typically triggers a tlsClientError event. When that happens, even though the servername has been received and SNICallback has been called successfully, the servername field is still not set on the TLS socket provided with the event. For successful connections however (i.e. secureConnection), it is always available.

This is because it's only set on the socket in _finishInit, which is only gets called after a successful handshake has been completed:

node/lib/_tls_wrap.js

Lines 735 to 747 in 495822f

	TLSSocket.prototype._finishInit = function() {
	// Guard against getting onhandshakedone() after .destroy().
	// * 1.2: If destroy() during onocspresponse(), then write of next handshake
	// record fails, the handshake done info callbacks does not occur, and the
	// socket closes.
	// * 1.3: The OCSP response comes in the same record that finishes handshake,
	// so even after .destroy(), the handshake done info callback occurs
	// immediately after onocspresponse(). Ignore it.
	if (!this._handle)
	return;
	this.alpnProtocol = this._handle.getALPNNegotiatedProtocol();
	this.servername = this._handle.getServername();

It'd be very useful if this field was set earlier, as soon as the server name has been received, to provide extra context to TLS errors like these.

[bnoordhuis]

I'd say you're welcome to open a pull request but there may be some edge cases you'll have to handle. At least some of the time 'tlsClientError' will be emitted before the SNI extension has been parsed.