You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Will Nordmeyer <qu...@gmail.com> on 2013/02/13 19:49:33 UTC
SSL Session Caching
I have a scenario right now I need help with.
My Tomcat is configured for SSL, client certificate authorization and
Certificate Revocation List checking (all outside certificates).
We have a scenario (we've found in testing) where we do a transaction
in our application, then the user pulls his smart card out (client
certificate) and a new user comes up and puts his card in. Tomcat
isn't recognizing that a new certificate is in place and is allowing
the new user, with the new certificate to transact without validating
his credentials.
It appears as if the old session is being utilized still by the client
(windows or unix, firefox or IE) and Tomcat. Which seems very odd.
I would have expected the new cert would have forced a new SSL session
to be created and tomcat to puke at an attempt to submit a transaction
on the old session.
Any thoughts/advice/guidance?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL Session Caching
Posted by André Warnier <aw...@ice-sa.com>.
Will Nordmeyer wrote:
> I have a scenario right now I need help with.
>
> My Tomcat is configured for SSL, client certificate authorization and
> Certificate Revocation List checking (all outside certificates).
>
> We have a scenario (we've found in testing) where we do a transaction
> in our application, then the user pulls his smart card out (client
> certificate) and a new user comes up and puts his card in. Tomcat
> isn't recognizing that a new certificate is in place and is allowing
> the new user, with the new certificate to transact without validating
> his credentials.
>
> It appears as if the old session is being utilized still by the client
> (windows or unix, firefox or IE) and Tomcat. Which seems very odd.
>
> I would have expected the new cert would have forced a new SSL session
> to be created and tomcat to puke at an attempt to submit a transaction
> on the old session.
>
> Any thoughts/advice/guidance?
>
That sounds to me like a serious flaw either at the level of the client logic, or at the
level of the training and/or discipline of the users. Not at the level of the Tomcat server.
Analogy : a room is protected by a door that opens with a key. Only some people have that
key. One of these people opens the door with his key, leaves it open and walks away.
Another (unauthorised) person walks through the open door into the room (*). Who is
responsible ? the room ?
(*) whether or not the other person puts his own (wrong) key into the lock is irrelevant.
The door is already open.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Session Caching
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: SSL Session Caching
> OP reports that a new SmartCard is being inserted and either the old
> session persists (and the new user is allowed to masquerade as the old
> user) or the new user is not authenticated but still allowed to access
> their own resources. Sounds like the former, but it's worth asking.
Which still indicates that the _client_ isn't reacting to the smartcard being swapped for another one. Not much the server (Tomcat) can do about that, other than force re-authentication on every access (which would introduce another set of issues).
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL Session Caching
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Steven,
On 2/13/13 3:01 PM, Adamus, Steven J. wrote:
> Nothing is going on. When the smartcard is removed, nothing goes
> across the wire, so how could Tomcat possibly invalidate the
> session?
!!?
OP reports that a new SmartCard is being inserted and either the old
session persists (and the new user is allowed to masquerade as the old
user) or the new user is not authenticated but still allowed to access
their own resources. Sounds like the former, but it's worth asking.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEb988ACgkQ9CaO5/Lv0PCFsgCcDlhlJhACoMh2RSIpXVBOzgtm
MHwAn1JhRSiglldzKfScPjmvyBly8mYO
=NZsb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: SSL Session Caching
Posted by "Adamus, Steven J." <ST...@saic.com>.
Nothing is going on. When the smartcard is removed, nothing goes across
the wire, so how could Tomcat possibly invalidate the session?
-----Original Message-----
From: users-return-239719-STEVEN.J.ADAMUS=saic.com@tomcat.apache.org
[mailto:users-return-239719-STEVEN.J.ADAMUS=saic.com@tomcat.apache.org]
On Behalf Of Mark Thomas
Sent: Wednesday, February 13, 2013 11:36 AM
To: Tomcat Users List
Subject: Re: SSL Session Caching
On 13/02/2013 18:49, Will Nordmeyer wrote:
> I have a scenario right now I need help with.
>
> My Tomcat is configured for SSL, client certificate authorization and
> Certificate Revocation List checking (all outside certificates).
>
> We have a scenario (we've found in testing) where we do a transaction
> in our application, then the user pulls his smart card out (client
> certificate) and a new user comes up and puts his card in. Tomcat
> isn't recognizing that a new certificate is in place and is allowing
> the new user, with the new certificate to transact without validating
> his credentials.
>
> It appears as if the old session is being utilized still by the client
> (windows or unix, firefox or IE) and Tomcat. Which seems very odd.
>
> I would have expected the new cert would have forced a new SSL session
> to be created and tomcat to puke at an attempt to submit a transaction
> on the old session.
>
> Any thoughts/advice/guidance?
Use wireshark. If you provide it with your server's private key (should
be doable in a test environment) you'll be able to see exactly what is
(or isn't) going on.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL Session Caching
Posted by Mark Thomas <ma...@apache.org>.
On 13/02/2013 18:49, Will Nordmeyer wrote:
> I have a scenario right now I need help with.
>
> My Tomcat is configured for SSL, client certificate authorization and
> Certificate Revocation List checking (all outside certificates).
>
> We have a scenario (we've found in testing) where we do a transaction
> in our application, then the user pulls his smart card out (client
> certificate) and a new user comes up and puts his card in. Tomcat
> isn't recognizing that a new certificate is in place and is allowing
> the new user, with the new certificate to transact without validating
> his credentials.
>
> It appears as if the old session is being utilized still by the client
> (windows or unix, firefox or IE) and Tomcat. Which seems very odd.
>
> I would have expected the new cert would have forced a new SSL session
> to be created and tomcat to puke at an attempt to submit a transaction
> on the old session.
>
> Any thoughts/advice/guidance?
Use wireshark. If you provide it with your server's private key (should
be doable in a test environment) you'll be able to see exactly what is
(or isn't) going on.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org