Re: [OT] Recognizing certificate removal (SmartCard)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 12/5/12 5:07 PM, Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] Recognizing certificate removal (SmartCard) Too late (at least in the US); you just made it public... Shuks. Ok then, I'll have to be satisfied with the glory. The US patent law has changed (but may not go into effect until next year; not sure about the timing) so that credit is given to first-to-file, rather than first-to-invent, regardless of public disclosure. So, you may still have time... I need to file something similar to the following: A method of arranging printed characters in sequence to facilitate knowledge transfer I'll proceed to sue everyone who uses written communication. I'll bet I can file separate patents for each language and then slam people with multiple patent violations: people always sound more guilty when there are more counts to a violation. Which sounds more plausible, Apple sues Samsung for violating a patent claim or Apple sues Samsung for violating 1327 patent claims? - -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/ iEYEAREIAAYFAlDBJrcACgkQ9CaO5/Lv0PAl2QCguUWMPOUSQQiEa9O757V/5OoD lA0AnAyB5gdTQH0qdPDyVKPmbUmZO6In =6tlZ -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)
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: [OT] Recognizing certificate removal (SmartCard)
Will Nordmeyer wrote: ... 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, As far as I remember the classics, that in itself is already a flaw with regard to security, no ? but they use their CAC and the browser to access the web application. Presumably, your application is not the only one running on these workstations. So any other application must have similar issues. How do they resolve it ? Assuming that there are many client workstations, and assuming that you cannot control what's installed on them, then one way I can think of - but it is quite heavy - is to have every single one of your pages contain a java applet running at all times, which checks the presence of the card and does something drastic (or doesn't do something vital) in case the card isn't there, and which causes the server to drop the session) (I mention the doesn't do bit, to avoid the user simply disabling java in the browser) One way I could imagine this, would be to have the applet establish its own connection to the server (maybe on a different port, and send a regular ping to another application on the server which would keep track of valid sessions. Should the ping no longer come, this application would somehow tell the main one to abort the session. It all sounds a bit complicated, but maybe in a very security-conscious environment, this would be sellable ? (*) Note that in order for the browser-based java applet to gain access to the local card-reader, may require some special security settings too. (*) Come to think of it, it would be rather universal as a solution. and not so complex to set up. I may have to patent this idea... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
On 12/5/2012 1:35 PM, André Warnier wrote: ... (*) Come to think of it, it would be rather universal as a solution. and not so complex to set up. I may have to patent this idea... Too late (at least in the US); you just made it public... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
David kerber wrote: On 12/5/2012 1:35 PM, André Warnier wrote: ... (*) Come to think of it, it would be rather universal as a solution. and not so complex to set up. I may have to patent this idea... Too late (at least in the US); you just made it public... Shuks. Ok then, I'll have to be satisfied with the glory. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
On 12/5/2012 4:18 PM, André Warnier wrote: David kerber wrote: On 12/5/2012 1:35 PM, André Warnier wrote: ... (*) Come to think of it, it would be rather universal as a solution. and not so complex to set up. I may have to patent this idea... Too late (at least in the US); you just made it public... Shuks. Ok then, I'll have to be satisfied with the glory. You could always try a European patent; I'm not sure what their patent rules are... :-D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
David kerber wrote: On 12/5/2012 4:18 PM, André Warnier wrote: David kerber wrote: On 12/5/2012 1:35 PM, André Warnier wrote: ... (*) Come to think of it, it would be rather universal as a solution. and not so complex to set up. I may have to patent this idea... Too late (at least in the US); you just made it public... Shuks. Ok then, I'll have to be satisfied with the glory. You could always try a European patent; I'm not sure what their patent rules are... :-D When you consider that Amazon could patent the 1-click, and Apple a black screen with round corners, I'm not sure that there are any rules, anywhere. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Recognizing certificate removal (SmartCard)
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] Recognizing certificate removal (SmartCard) Too late (at least in the US); you just made it public... Shuks. Ok then, I'll have to be satisfied with the glory. The US patent law has changed (but may not go into effect until next year; not sure about the timing) so that credit is given to first-to-file, rather than first-to-invent, regardless of public disclosure. So, you may still have time... - 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: [OT] Recognizing certificate removal (SmartCard)
Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] Recognizing certificate removal (SmartCard) Too late (at least in the US); you just made it public... Shuks. Ok then, I'll have to be satisfied with the glory. The US patent law has changed (but may not go into effect until next year; not sure about the timing) so that credit is given to first-to-file, rather than first-to-invent, regardless of public disclosure. So, you may still have time... I'll probably need a more complete description, possibly even working code. And I'm not so confident in my Java skills. Any volunteer for helping and sharing in the glory, and maybe even the bucks then ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Recognizing certificate removal (SmartCard)
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). --Will - 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
