In a brief, can be long connections threated as security vulnerability? By long connections i mean connections where for long period of time data is not being sent at all. For example client-server connection when client or server has to retrive recived data and it take long period of time? Right now i'm working with system where devices are connecting to the system via gprs/3g/lte connections, sometimes it happens that system has to retrive data and it takes time. It looks like network or network device(Router, i dont have acces to the router configuration) timeout connection if no data has been sent in last 5 minutes, for me it looks like too short period of time. We can bypass 5 minutes limit by setting tcp_keepalive_time to lower value but maybe there are some security reasons for closing connection after 5 minutes?
-
With mobile devices you can regularly expect connection losses simply due to the device being moved somewhere where it doesn't have a signal anymore.– PhilippFeb 16, 2017 at 10:06
-
The forward secrecy features of SSL/TLS are rather ineffective for long running connections because keys that can decrypt the whole connection have to stay in memory until it ends (or rekey/renegotiate which is unusal).– CodesInChaosFeb 16, 2017 at 10:11
2 Answers
From an infosec standpoint, expiring TCP sessions are needed to reduce the possibility of exhausting resources on firewalls, routers and other equipment.
Keepalives help when higher level protocols take a long time between transmissions, e.g., when processing information client side.
The downside to keepalives, especially for wireless customers, is that a perfectly valid connection may be terminated if a keepalive packet is dropped. I.e., while TCP is a stateful protocol which normally retransmits in the event of packet loss and ACK's segment receipt, the absence of a reply to a keepalive could mean that the other end is down, or that a single packet was lost.
Depending on keepalives can create situations where users over unreliable connections have problems with the application which aren't reproducible.
These long TCP session timeouts might help a handful of customers, but, only if the customer gateway devices also have long session timeouts... then the home users, coffee shops etc.
The better solution for this an application layer keepalive or a URL callback.
The only problem that I can see arising out of this is: Multiple clients connect to your server, thus eating up its resources and effectively creating a Denial-of-service condition.
