Reusing TLS sessions causes to socket.servername being false with Repro

[ackava]

Version

22

Platform

All Platforms

Subsystem

TLS

What steps will reproduce the bug?

There was already an issue that is closed #28985, however I could not reopen the issue again, but I have a confirmed repro sample that is still an issue.

Following repository contains the code to reproduce the issue.
https://github.com/ackava/node-tls-servername-false

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

The issue occurs from .NET HTTP Client, now .NET has widespread usage and variety of services connect to web servers hosted on node and specific TLS Session reuse from HttpClient from dotnet causes this bug.

To isolate the bug, I have separated TLS and HTTP1 layer, now I have an application where in I am offloading TLS in node cluster and forwarding connections to appropriate virtual hosts (every host has a separate application and separate SSL certificate).

What is the expected behavior? Why is that the expected behavior?

TLSSocket's servername should be SNI host.

What do you see instead?

When TLS Session is resumed, servername is false.

Additional information

However, switching to dotnet or any other framework, it is found that servername is available even after resumed session. Other frameworks store servername along with any session/ticket reuse that should be applied when session is resumed.

Currently I moved TLS outside nodejs and put it as a separate container and it serves the purpose. But Node's TLS is broken as when session is resumed, there is no way to get current certificate, current servername, everything is empty.

Possible Solutions

There is an easy way to fix this, by saving SNI host in session buffer for session resumption, this would fix the issue.

[siggi-gross]

as i stated in my concluding post
nodejs/help#4466 (comment)

some clients try to reuse tlsSession on IP basis (for good) ...
while others reuse tlsSessions for "not so good reasons"..

either way, clients DO switch (sub)domain/host mid-session

as you have multiple hosts, your workaround will inevitably end up redirecting to another virtual host with the wrong TLS credentials/session

it's not a bug in TLS, (someone stated "it's known behaviour")
rather the fact that SNI is not enforced on session resumption
and therefore may be exploited.

from a security point of view:

• a client who wants to reuse a session without providing SNI cannot be trusted
• we have no way to force a session renegotiation with SNI

so the only secure way to handle those cases is to terminate the session with a meaningful response and leave it to the client to reconnect.

421 Misdirected Request is the most appropriate for those cases.

in your case you have control over both ends of the connection.
it should be pretty straightforward to catch a 421 in your .NET application and reconnect.

[ackava]

@siggi-gross , when I check the client hello, client sends SNI header along with the request to reuse session, so client is sending SNI along with session. It is node TLS code that doesn't attach the SNI header, however other web servers manage this correctly. And in .NET, there is no way to force reconnect if we get 421, as TLS session is managed outside of user's code and only alternative is to disable TLS session reuse.

Also 421 is only in the scope of HTTPS, we cannot use same method for other protocols such as SMTP, IMAP etc.