TLS握手失败但未关闭连接：服务器为何仍对Telnet客户端的报文进行ACK应答？

Great question! This boils down to a key distinction between the TCP transport layer and the TLS application layer security protocol—they operate independently, even when used together. Let's break down what's happening in your experiment:

• TCP connections are separate from TLS handshakes
  Before any TLS handshake even starts, your Telnet client completed a full TCP three-way handshake with the server. That means a reliable transport connection is already established at the TCP layer. The failed TLS handshake is an application-layer failure, but it doesn't automatically tear down the underlying TCP connection. The TCP stack on the server doesn't care about the content of the data (whether it's valid TLS handshake messages or random Telnet strings)—it only cares about confirming that data was received correctly, hence the ACK responses to your PSH, ACK packets.

• Server behavior after TLS handshake failure
  Most TLS server implementations don't immediately close the TCP connection when a handshake fails (unless configured to do so). Instead, they might simply discard the invalid TLS traffic at the application layer, but leave the TCP connection open. This is why the server can still accept new client connections (since its listening socket is unaffected) while continuing to ACK data from the original Telnet client—those are two separate TCP connections (or one open connection and a new incoming one).

• No error feedback to Telnet
  Telnet isn't a TLS-aware client, so even if the server sent a TLS alert message (the standard way to signal handshake failures), Telnet wouldn't interpret it as an error. Additionally, some servers might not send an alert at all for invalid initial traffic (like Telnet's plaintext), which is why you don't see any failure message in the client.

• The "successful TLS handshake + more Telnet messages" in your Wireshark capture
  That successful handshake is almost certainly a new TCP connection from a TLS-aware client to the server's listening port. The existing Telnet connection remains open (and the server's TCP stack keeps ACKing its packets) until either the client closes it, the server times out the idle connection, or the server explicitly closes it later.

To sum it up: The ACK responses are purely TCP-layer behavior, unrelated to the success or failure of the TLS handshake above it. The TCP connection stays alive unless explicitly terminated, so the server keeps acknowledging received data even when it can't process it at the TLS/application layer.

内容的提问来源于stack exchange，提问作者lior.i