Re: Recognizing certificate removal (SmartCard)
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Will, On 12/4/12 2:47 PM, Will Nordmeyer wrote: Thanks for the quick response and the thoughts. a 5 minute timeout wouldn't be acceptable in our environment - theory being, if user A pulls his smart card out (but didn't log out of the app), and user B goes up to the machine within 5 minutes, he may have access to someone else's account in the application. So I was really hoping there was some way to trigger the session to expire. The only thing I can think of would be to have the web browser complicit in the deal: if the browser can be configured to expire the SSL session when the card is removed, then that is really the only solution that will be truly secure. I'll keep looking, or suggest to my dev team that they write a little app that queries the card regularly and as soon as the card can't be found, logs out. Is it a valid use case to have the computer itself logged-in when the card is removed? For instance, if you configured the machine to auto-lock when the card was removed, then you might be able to do other things, too (like kill the browser, which should kill the SSL session). Sorry for barging in where I know little myself. In the thread Tomcat 7 SSL Session ID, a recent post by EJP may have a bearing on this discussion, maybe. Other than that, and without any pretense at offering a solution to the present issue, maybe this is the point where one needs to step back and ask oneself if this is really a problem of the application. If the environment is such that it is a concern that one might login using a card, then remove the card and walk away, leaving the workstation logged-in and a session open with some security-conscious application, for someone else to use at will, then maybe this is not a problem of the application at the other end, but a problem with the environment ? What for example if that same person walks away while leaving their card in the reader ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
On Tue, Dec 4, 2012 at 3:07 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Will, On 12/4/12 2:47 PM, Will Nordmeyer wrote: Thanks for the quick response and the thoughts. a 5 minute timeout wouldn't be acceptable in our environment - theory being, if user A pulls his smart card out (but didn't log out of the app), and user B goes up to the machine within 5 minutes, he may have access to someone else's account in the application. So I was really hoping there was some way to trigger the session to expire. The only thing I can think of would be to have the web browser complicit in the deal: if the browser can be configured to expire the SSL session when the card is removed, then that is really the only solution that will be truly secure. That's a potential, but there are quite a few clients so I'm not sure we can impact the clients... interesting scenario we've got. I'll keep looking, or suggest to my dev team that they write a little app that queries the card regularly and as soon as the card can't be found, logs out. Is it a valid use case to have the computer itself logged-in when the card is removed? For instance, if you configured the machine to auto-lock when the card was removed, then you might be able to do other things, too (like kill the browser, which should kill the SSL session). Oddly enough, yes, it is a valid use case. we have specific scenarios where there are common use PCs that have a generic ID logged in, but they use their CAC and the browser to access the web application. - -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+WBUACgkQ9CaO5/Lv0PBmeACeN5Y/m0G73Mplzufsys70uZPZ EsoAn0Lh/cuM4vtC6Y5B8QekaDXff7eE =mSK7 -END PGP SIGNATURE- - 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: Recognizing certificate removal (SmartCard)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 12/5/12 3:12 AM, André Warnier wrote: Other than that, and without any pretense at offering a solution to the present issue, maybe this is the point where one needs to step back and ask oneself if this is really a problem of the application. You're right: this is not a problem of the application (at least, not the web application itself). Unfortunately, it's an operation requirement which means it must be solved *somewhere*. At this point, we're way off-topic where Tomcat is concerned. ;) If the environment is such that it is a concern that one might login using a card, then remove the card and walk away, leaving the workstation logged-in and a session open with some security-conscious application, for someone else to use at will, then maybe this is not a problem of the application at the other end, but a problem with the environment ? What for example if that same person walks away while leaving their card in the reader ? Court martial. :) - -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/cUQACgkQ9CaO5/Lv0PAXGQCdGPdtFnEl8Cz0zpk9m9+GXMmc Ms4Aniaxee53v/UY2ZGx8mFYd/CtlI3Z =mHTz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Will, On 12/5/12 7:33 AM, Will Nordmeyer wrote: On Tue, Dec 4, 2012 at 3:07 PM, Christopher Schultz ch...@christopherschultz.net wrote: Will, On 12/4/12 2:47 PM, Will Nordmeyer wrote: Thanks for the quick response and the thoughts. a 5 minute timeout wouldn't be acceptable in our environment - theory being, if user A pulls his smart card out (but didn't log out of the app), and user B goes up to the machine within 5 minutes, he may have access to someone else's account in the application. So I was really hoping there was some way to trigger the session to expire. The only thing I can think of would be to have the web browser complicit in the deal: if the browser can be configured to expire the SSL session when the card is removed, then that is really the only solution that will be truly secure. That's a potential, but there are quite a few clients so I'm not sure we can impact the clients... interesting scenario we've got. I'll keep looking, or suggest to my dev team that they write a little app that queries the card regularly and as soon as the card can't be found, logs out. Is it a valid use case to have the computer itself logged-in when the card is removed? For instance, if you configured the machine to auto-lock when the card was removed, then you might be able to do other things, too (like kill the browser, which should kill the SSL session). Oddly enough, yes, it is a valid use case. we have specific scenarios where there are common use PCs that have a generic ID logged in, but they use their CAC and the browser to access the web application. Okay, good to know. Well, the OS can certainly detect when the CAC has been removed. I think it's time to talk to some of the desktop IT folks to see what your options are. This is something that is going to have to be solved on the client side, not the server side. Now, if the CAC is definitely required in order to establish an SSL connection (can you confirm that? It's kind of important for my whole line of thinking, here), you could simply set the SSL session timeout to something typically considered foolishly low (like 1 second). That will significantly impact performance (every request will require a new SSL key negotiation), but should ultimately fulfill your requirement: the only way for a CAC to be removed yet still allow a post-withdraw request would be if the new and old users were face-to-face (discounting the usual edge-cases that crop-up on this list occasionally, like unlikely quantum phenomena, interference from Time Lords, etc.). It cannot, of course, prevent any physical attack (or mistake) on the client side such as one user taking another's CAC or a user forgetting to remove the card from the slot before leaving a terminal. You can fix those vectors with robust cables attaching the CAC to the user's pelvic bone, which I hear will be implemented starting in 2013. - -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/c48ACgkQ9CaO5/Lv0PB+1QCfRh43nJbEPtxcE//0y5rXluNe pQIAnRoOlpByn9bEAU31gp99pXt6WnWc =RZ6x -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Will, On 12/4/12 12:08 PM, Will Nordmeyer wrote: First off, thanks to all for the assistance getting my other tomcat CRL issues working. Converted to APR and tcnative and things seem to be loading, running well now. Now, the question has come up - what happens when a user authenticates with their Smart Card, but then pulls their card and walks away. Is there a way for Tomcat to detect such an event on the client and terminate/timeout the session? In the googling I've done, I've seen suggestions about writing a little java app that runs within our application and periodically pulls something from the SmartCard - when the app fails to get that piece of info, it terminates the app. Is that the way to go? (and if so, is there sample code - I know this isn't a java forum, but if someone's invented this wheel before, that would be great). I'm certainly no SSL expert (especially with SmartCards involved), but if the SmartCard is required in order to set up an SSL session, you could set the SSL session timeout to some small-ish value (say, 10 minutes -- the default is 24 hours) and then require a new SSL session to be established every 10 minutes. That would require the SmartCard to be present for that renegotiation (this is my assumption). That way, you don't have to write any new software and maintain it on the client. Check out the sessionTimeout attribute on the HTTP/SSL connector. Hmm... I just re-checked and that option is currently only available for the pure-Java connectors -- and you just switched to APR to get your huge CRLs working. :( OpenSSL does have an SSL_CTX_set_timeout method, but it doesn't have any support through tcnative. If this is something that would help you, please let me know and I'll take a stab at implementing a tcnative method for this and then expose it through the Connector configuration. - -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+NugACgkQ9CaO5/Lv0PCoawCeLe2nvXK5kbzYx5c+eKt4ruhm e20AoLWE+CFWc9oDcwlmmWcjv+JuhF76 =u0KH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Will, On 12/4/12 12:46 PM, Christopher Schultz wrote: On 12/4/12 12:08 PM, Will Nordmeyer wrote: First off, thanks to all for the assistance getting my other tomcat CRL issues working. Converted to APR and tcnative and things seem to be loading, running well now. Now, the question has come up - what happens when a user authenticates with their Smart Card, but then pulls their card and walks away. Is there a way for Tomcat to detect such an event on the client and terminate/timeout the session? In the googling I've done, I've seen suggestions about writing a little java app that runs within our application and periodically pulls something from the SmartCard - when the app fails to get that piece of info, it terminates the app. Is that the way to go? (and if so, is there sample code - I know this isn't a java forum, but if someone's invented this wheel before, that would be great). I'm certainly no SSL expert (especially with SmartCards involved), but if the SmartCard is required in order to set up an SSL session, you could set the SSL session timeout to some small-ish value (say, 10 minutes -- the default is 24 hours) and then require a new SSL session to be established every 10 minutes. That would require the SmartCard to be present for that renegotiation (this is my assumption). That way, you don't have to write any new software and maintain it on the client. Check out the sessionTimeout attribute on the HTTP/SSL connector. Hmm... I just re-checked and that option is currently only available for the pure-Java connectors -- and you just switched to APR to get your huge CRLs working. :( OpenSSL does have an SSL_CTX_set_timeout method, but it doesn't have any support through tcnative. If this is something that would help you, please let me know and I'll take a stab at implementing a tcnative method for this and then expose it through the Connector configuration. Answering my own question somewhat: the default SSL session timeout for OpenSSL is actually 300 seconds (5 minutes) so that might work for you. Of course, I might be wrong about the session timeout requiring the SmartCard to be present for renegotiation. Let me know what you find out. - -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+N3QACgkQ9CaO5/Lv0PCOEQCgjv/OEhRGix5DMYJNsJam389C NW4Ani2k+j+D3AfJ+q8i+UqssCCPAKLT =Xz5U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
On Tue, Dec 4, 2012 at 12:48 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Will, On 12/4/12 12:46 PM, Christopher Schultz wrote: On 12/4/12 12:08 PM, Will Nordmeyer wrote: First off, thanks to all for the assistance getting my other tomcat CRL issues working. Converted to APR and tcnative and things seem to be loading, running well now. Now, the question has come up - what happens when a user authenticates with their Smart Card, but then pulls their card and walks away. Is there a way for Tomcat to detect such an event on the client and terminate/timeout the session? In the googling I've done, I've seen suggestions about writing a little java app that runs within our application and periodically pulls something from the SmartCard - when the app fails to get that piece of info, it terminates the app. Is that the way to go? (and if so, is there sample code - I know this isn't a java forum, but if someone's invented this wheel before, that would be great). I'm certainly no SSL expert (especially with SmartCards involved), but if the SmartCard is required in order to set up an SSL session, you could set the SSL session timeout to some small-ish value (say, 10 minutes -- the default is 24 hours) and then require a new SSL session to be established every 10 minutes. That would require the SmartCard to be present for that renegotiation (this is my assumption). That way, you don't have to write any new software and maintain it on the client. Check out the sessionTimeout attribute on the HTTP/SSL connector. Hmm... I just re-checked and that option is currently only available for the pure-Java connectors -- and you just switched to APR to get your huge CRLs working. :( OpenSSL does have an SSL_CTX_set_timeout method, but it doesn't have any support through tcnative. If this is something that would help you, please let me know and I'll take a stab at implementing a tcnative method for this and then expose it through the Connector configuration. Answering my own question somewhat: the default SSL session timeout for OpenSSL is actually 300 seconds (5 minutes) so that might work for you. Of course, I might be wrong about the session timeout requiring the SmartCard to be present for renegotiation. Let me know what you find out. - -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+N3QACgkQ9CaO5/Lv0PCOEQCgjv/OEhRGix5DMYJNsJam389C NW4Ani2k+j+D3AfJ+q8i+UqssCCPAKLT =Xz5U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Chris, Thanks for the quick response and the thoughts. a 5 minute timeout wouldn't be acceptable in our environment - theory being, if user A pulls his smart card out (but didn't log out of the app), and user B goes up to the machine within 5 minutes, he may have access to someone else's account in the application. So I was really hoping there was some way to trigger the session to expire. I'll keep looking, or suggest to my dev team that they write a little app that queries the card regularly and as soon as the card can't be found, logs out. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Will, On 12/4/12 2:47 PM, Will Nordmeyer wrote: Thanks for the quick response and the thoughts. a 5 minute timeout wouldn't be acceptable in our environment - theory being, if user A pulls his smart card out (but didn't log out of the app), and user B goes up to the machine within 5 minutes, he may have access to someone else's account in the application. So I was really hoping there was some way to trigger the session to expire. The only thing I can think of would be to have the web browser complicit in the deal: if the browser can be configured to expire the SSL session when the card is removed, then that is really the only solution that will be truly secure. I'll keep looking, or suggest to my dev team that they write a little app that queries the card regularly and as soon as the card can't be found, logs out. Is it a valid use case to have the computer itself logged-in when the card is removed? For instance, if you configured the machine to auto-lock when the card was removed, then you might be able to do other things, too (like kill the browser, which should kill the SSL session). - -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+WBUACgkQ9CaO5/Lv0PBmeACeN5Y/m0G73Mplzufsys70uZPZ EsoAn0Lh/cuM4vtC6Y5B8QekaDXff7eE =mSK7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org