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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL Session Caching
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@tomcat.apache.org [mailto:users-return-239719-STEVEN.J.ADAMUS=saic@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Session Caching
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL Session Caching
From: Christopher Schultz [mailto:ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Session Caching
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
