Re: [OT] Tomcat 7 SSL Session ID

[André Warnier <aw...@ice-sa.com>]

Esmond Pitt wrote:
> 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
> SSLSessionContext.
>  
Ah.  That would explain some other (totally unrelated) phenomenon which I had noticed and 
which puzzled me.
I didn't know that. Thanks for the info.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Tomcat 7 SSL Session ID

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

André,

On 12/5/12 2:49 AM, André Warnier wrote:
> Esmond Pitt wrote:
>> 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 SSLSessionContext.
>> 
> Ah.  That would explain some other (totally unrelated) phenomenon
> which I had noticed and which puzzled me. I didn't know that.
> Thanks for the info.

Yes. SSL sessions are essentially an optimization because SSL key
exchange and setup are fairly expensive (it uses asymmetric,
public-key encryption which is sloooow). Once the session is
established, a symmetric encryption key is used and the client and
server generally refer to the session id for a period of time.

At some interval, the session is re-negotiated ostensibly to improve
security (to limit the lifetime of the encryption keys) though there
have been some vulnerabilities identified in recent years (you have
probably heard the phrase "unsafe renegotiation") with this mechanism.

When the session times out (or is explicitly destroyed... I don't know
the specific mechanism for accomplishing this as the client is not
guaranteed to ever return for more data), everything must be
renegotiated from scratch and a new session is created.

Again, this has absolutely nothing to do with HttpSession, nor does it
really have anything to do with HTTP at all -- that just happens to be
the protocol tunneled through TLS in this case. The fact that the OP
is playing around with keepalive timeouts really shouldn't have any
bearing on what's going on, here: Tomcat's documentation says that the
default SSL session timeout is 24 hours. That means that, 24 hours
after a client makes a single SSL connection, Tomcat will expire the
session. I don't know that a client can specifically ask the server to
expire an SSL session. So, something weird is definitely going on. I
can't yet figure out if this is a Tomcat bug, a configuration snafu,
or a complete misunderstanding of SSL sessions on the OP's part.

Honestly, I was hoping that after extracting more information from the
OP, someone with more low-level knowledge of JSSE and/or OpenSSL
(Filip or Konstantin, probably) would chime-in with some more useful
thoughts.

The "description" section on Wikipedia is definitely worth the read:
http://en.wikipedia.org/wiki/Transport_Layer_Security

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlC/cI8ACgkQ9CaO5/Lv0PDVeQCgw02zqPBMWIIoIuhlXd18NHd/
UmUAn0vj2QxtyrYPN5s7MJWZeChG4zj8
=CfQX
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org