What is the security risk of enabling persistent connection (HTTP Keep-Alive)?

Question

By my understanding, the HTTP Keep-Alive header dictates whether the next packet of communication will be sent over the same connection or not, i.e., if the web app runs over SSL, and a Keep-Alive is enabled for, say 60 seconds, then:

-any client-server communication will take place over the same connection
-any client-server communication after 60 seconds of inactivity will reinitiate the SSL handshake and then proceed with requests and repsonses.

Also, how is this connected to a user's session inactivity timeout?

Answer 1

whether the next packet of communication will be sent over the same connection or not

Nearly but not exactly. There is not "packet" at this level of communication, just a data stream. HTTP-Keep-alive will allow multiple HTTP requests over the same TCP/TLS connection instead of only one by not closing the connection immediately after the HTTP response but instead keeping it open for more requests.

HTTP Keep-Alive header dictates

No, it dictates nothing. By adding Connection: keep-alive to the query (or implicitly by using HTTP/1.1 instead of HTTP/1.0) the client is asking the server politely to not close the TCP connection after the response is done. The server might agree or it might not.

any client-server communication will take place over the same connection

Not necessarily. There might be multiple TCP/TLS connections open in parallel between browser and server.

any client-server communication after 60 seconds of inactivity will reinitiate the SSL handshake and then proceed with requests and repsonses.

Client and server can decide to close the idle connection (i.e. no outstanding response) at any time and both have their independent settings and timers. If the connection is closed and the client wants to make a new request it needs to create a new TCP connection and for HTTPS it needs either to resume an existing SSL session on top of this TCP connection or to do a full TLS handshake for a new SSL session.

Also, how is this connected to a user's session inactivity timeout?

This is completely unrelated. User sessions are managed at the application level. HTTP keep alive is managed at the HTTP protocol level. You can have multiple user sessions within a single TCP connection (with multiple HTTP requests) and you can also have a user session be kept over multiple TCP connections (both after each other and also parallel connections).

What is the security risk of enabling persistent connection (HTTP Keep-Alive)?

There is none.

Answer 2

The only reason I can think of it being bad is it being used in DDoS attacks.

Slowloris is a type of denial of service attack tool invented by Robert "RSnake" Hansen which allows a single machine to take down another machine's web server with minimal bandwidth and side effects on unrelated services and ports.

Slowloris tries to keep many connections to the target web server open and hold them open as long as possible. It accomplishes this by opening connections to the target web server and sending a partial request. Periodically, it will send subsequent HTTP headers, adding to—but never completing—the request. Affected servers will keep these connections open, filling their maximum concurrent connection pool, eventually denying additional connection attempts from clients.

Source: https://en.wikipedia.org/wiki/Slowloris_(computer_security)

Similar to the above DDoS attack, an attacker could open as many connections as possible, depending on the size of the botnet it can be a very large number and it could block connections of real users.