tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Esmond Pitt" <>
Subject RE: Tomcat 7 SSL Session ID
Date Tue, 04 Dec 2012 22:57:38 GMT
Broken pipes don't invalidate the SSL session. They just break the TCP
connection. The SSL session persists, across multiple TCP connections, until
it is specifically invalidated by someone: for example, timed out by the


From: Vincent Goelen [] 
Sent: Wednesday, 5 December 2012 1:15 AM
To: Tomcat Users List
Subject: Re: Tomcat 7 SSL Session ID


thanks for the help! 

To be clear, I do not want a 0ms timeout... I'm doing research about how
"usable" the SSL session tracking option is for session management...
With the standard settings it seems very unstable to me, when sending alot
of parallel requests I get a broken socket error invalidating the ssl
session and making the session with this id disappear. In this case it would
seem to me that it's easy to create Denial of Service attacks by just
sending alot of requests so the user loses his session.

By playing with the timeouts I found out this problem doesn't occur when I
set the timeout to 0, just by playing with the settings. Perhaps because
this disables the possibility of too many parallel connections? I can't find
the reason of this in the Tomcat or SSL specs... 

I've added a screenshot of a capture where things go wrong without setting a
keepAlive.. So I send alot of requests to the server, the first clientHello
(pck 38943) and the following packets everything goes ok, when the
application data is being send I get a tcp rst from port 54195 (this is the
connection that was used for the transactions before the current one) ... At
this moment my session gets invalidates making the next SSL handshake a full
one with new ID (pckt 40361, ...)

2012/11/29 Christopher Schultz <>

Hash: SHA1


On 11/28/12 3:14 AM, Vincent Goelen wrote:
> When the keepAliveTimeout is not set to "0" I can see in the SSL
> debug logs the SSL session get's invalidated after some requests
> with a Broken Pipe exception. Is this because there are too many
> open connections during the keepAliveTimeout?

It's probably because of your pathological keepAliveTimeout. 0ms
seems, er, low. Why did you choose 0ms?

I haven't looked at the code, so I'm not sure if the elapsed timer
starts when the last request is completed (which seems reasonable) or
when the last request started. I suspect the latter. 0ms is awfully
short. Are you sure that your client is capable of accepting the
response to the previous request and turn-around and make another
request across the same channel before 0ms passes?

> It also only happens when processing the requests takes some time
> (fe. storing items in database) or when I put the threat to sleep
> for testing purpose.

So if you have a trivial request (say, HEAD for a static resource),
you can never get a failure?

> When inspecting the traffic I see some tcp-rst packages (problem is
> here?) from previous connections while the current one is being
> processed.

When you say "current one" what do you mean? If you are using a single
connection with HTTP keepalive, then there is only one connection to
talk about: you can't get RSTs from "previous connections". You may be
getting TCP RST as the server closes the connection while the client
is trying to write. Is that what you are experiencing?

> My question is why these SSL Sessions get invalidated after alot of
> quick requests to the server since this gives a problem with my SSL
> Session tracking since the id changes then.

Maybe if you can explain why you want a 0ms keepalive timeout it would
be helpful. If you want to disable keep alives, set
maxKeepAliveRequests="1". If you want to allow an infinite timeout,
try using keepAliveTimeout="-1" as the documentation states.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with undefined -


To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message