Home/ Questions/Q 1008779
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T08:49:26+00:00

Scenario: 2 network devices, each on separate private LANs. The LANs are connected by

  • 0

Scenario: 2 network devices, each on separate private LANs. The LANs are connected by public Internet.

Device on network A is listening on a socket; network A firewall has NAT port forward setup for external access from network B’s port range.

Device on network B makes outgoing connection to network A to connect to the listen socket.

Is there any difference in vulnerability of short-term connection made for a data transfer then dropped when complete (e.g. few seconds), and a persistent connection which employs a keep-alive mechanism and reconnects when dropped (hours, days, ..)?

The security of actually making the connection is not part of my question.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    the client will maintain a persistent connection to server

    No such thing exists.

    Each connection — no matter how long it’s supposed to last — will eventually get disconnected. It may be seconds before the disconnect or centuries, but it will eventually get disconnected. Nothing is “persistent” in the sense of perpetually on.

    There is no such thing as a “keep-alive mechanism”. It will get disconnected.

    “Assume the server authenticates the client upon connection”. Can’t assume that. That’s the vulnerability. Unless you have a secure socket layer (SSL) to assure that the TCP/IP traffic itself is secure. If you’re going to use SSL, why mess around with “keep-alive”?

    When it gets disconnected, how does it get connected again? And how do you trust the connection?

    Scenario One: Denial of Service.

    1. Bad Guys are probing your socket waiting for it to accept a connection.

    2. Your “persistent” connection goes down. (Either client crashed or you crashed or network routing infrastructure crashed. Doesn’t matter. Socket dead. Must reconnect.)

    3. Bad Guys get your listening socket first. They spoof their IP address and you think they’re the client. They’re in — masquerading as the client.

    4. The client host attempts their connection and you reject it saying they’re already connected.

    Indeed, this is the exact reason why folks invented and use SSL.

    Based on this, you can dream up a DNS-enabled scenario that will allow Bad Guys to (a) get connected and then (b) adjust a DNS entry to make them receive connections intended for you. Now they’re in the middle. Ideally, DNS security foils this, but it depends on the client’s configuration. They could be open to DNS hacks, who knows?

    The point is this.

    Don’t Count On A Persistent Connection

    It doesn’t exist. Everything gets disconnected and reconnected. That’s why we have SSL.

    The client can simply reconnect, the server must respond to the user request with the appropriate error.

    False. The client cannot “simply” reconnect. Anyone can connect. Indeed, you have to assume “everyone” is trying to connect and will beat the approved client.

    To be sure it’s the approved client you have to exchange credentials. Essentially implementing SSL. Don’t implement your own SSL. Use existing SSL.

    would they have to break into a switch site?

    Only in the movies. In the real world, we use packet sniffers.

    • 0