TLS连接超时与TCP连接超时：攻击场景下的连接存活判定问题

Great question—let’s break this down clearly, since it cuts to how TLS depends on lower-layer TCP mechanics and application-level logic.

First, a key foundational point: TLS itself doesn’t have a built-in standalone timeout mechanism to detect a dead peer when the underlying TCP connection is being artificially kept alive. The TLS Heartbeat extension (which you noted isn’t enabled here) was designed specifically to add peer reachability checks at the TLS layer, but without it, TLS entirely relies on other layers to detect a dead connection.

Let’s walk through the scenario step by step:

• When Alice terminates her application, her OS’s TCP stack would normally send a FIN or RST packet to close the connection. But if the attacker is intercepting these packets and spoofing keepalive responses to make Bob’s TCP stack think the connection is still alive, the TCP connection will stay in the ESTABLISHED state from Bob’s perspective.
• Without TLS Heartbeat, Bob’s TLS stack has no way to independently verify if Alice is actually present. So the TLS connection will remain "open" as long as the TCP connection appears alive—unless one of two things happens:
  1. TCP Keepalive is enabled: If Bob’s TCP stack is configured with TCP Keepalive (a standard TCP feature, not TLS-specific), after a configured idle period, it will send keepalive probes to Alice. Since Alice is gone, even if the attacker tries to spoof responses, eventually (after failed probes) the TCP stack will mark the connection as dead and close it—taking the TLS connection down with it.
  2. Application-level timeout logic: If Bob’s application has its own timeout (e.g., closing the connection if no application data is received for X minutes), it will actively terminate the TLS connection regardless of the TCP state.
  3. Bob tries to send data: If neither TCP Keepalive nor application timeouts are configured, Bob’s TLS connection will stay open until his application attempts to send data. At that point, either the attacker can’t spoof a valid TLS-level response (leading to a TLS alert and connection closure) or the TCP layer will eventually detect the failure (if the attacker doesn’t acknowledge the data) and close the connection.

In short: Without TLS Heartbeat, Bob won’t close the TLS connection due to a TLS-specific timeout. The closure depends entirely on TCP-level keepalive settings or application-level logic to detect the dead peer. If neither is in place, the connection could hang indefinitely (from Bob’s perspective) until a data transfer attempt exposes the dead peer.

内容的提问来源于stack exchange，提问作者qweruiop