I'm an IIS admin. I've done the best I can with mod_ssl documentation, google, etc, and can't find anyone else who's even experienced my problem, much less found a solution. That, of course, makes me wonder whether I'm even understanding it correctly, but I see it plain as day in my WireShark traces.
I've got a race condition with a slow IIS server. The IIS server successfully TLS connects to my Apache server, and sends an encrypted request. The Apache server responds successfully, and the IIS server is usually happy and done. 5 seconds later, a TLS Rec Layer-1 Encrypted Alert is transmitted by the Apache server and the TLS conversation is terminated. Every now and again, though, the negotiation is complicated by the client server when it submits a second or third encrypted request through the existing, open TLS channel. 999 times in 1000 all these negotiations are flawless.
1 time in 1000 the slow IIS server takes exactly 5 seconds to decide to send an additional encrypted request (TLS Application Data). When this happens, the encrypted request crosses the TLS Rec Layer-1 Encrypted Alert on the wire, resulting in "The underlying connection was closed: The connection was closed unexpectedly."
I don't see any directive in mod_ssl that allows me to extend that 5 second conversation timeout. What am I overlooking?
I'm able to modify the SSLSessionCacheTimeout directive, but that has no impact on the 5 second timeout around any particular conversation. Has anyone else seen this kind of behavior?
Best Answer
Sounds like each application request is a separate HTTP call - in which case our culprit is likely
KeepAliveTimeout- the default of which happens to be 5 seconds.Turning off HTTP keep-alive altogether would resolve the issue, but would also be detrimental to performance, requiring new TCP then TLS handshakes for each request. Instead, would it be less likely to have a crossing-on-the-wire race condition if you bumped the timeout to, say, a minute or higher - or is the application sending requests all the time? As long as the Apache server's not getting a lot of connections, there shouldn't be any detriment to increasing this value.
Maybe just try: