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?

  • Can you clarify how it's communicating in HTTP terms? Is the application taking 5 seconds to complete the first request, or is the second "burst" a second HTTP request? – Shane Madden Feb 17 '12 at 19:55
  • Thanks, Shane. I've modified the question to hopefully be more complete. What I see in Wireshark is multiple bursts of encrypted SSL Application Data. As a rule I see one large reply from the Apache server, then 5 seconds of sleep and the termination alert. I'm assuming each burst of ssl app data represents a new request, but since it's all hashed I can't really tell. – codepoke Feb 17 '12 at 20:01

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:

KeepAliveTimeout 120
  • Shane, you're exactly right. I modified the keepalive, and the encrypted alert now fires after <keepalive /> seconds. Thank you! – codepoke Feb 17 '12 at 21:04
  • codepoke: You should accept Shane's answer so that others are more willing to help you in the future. – Doug Feb 17 '12 at 22:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.