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 2012/12/04 18:08:04 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
Posted by David kerber <dc...@verizon.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: André Warnier [mailto:aw@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chuck,
On 12/5/12 5:07 PM, Caldarale, Charles R wrote:
>> From: André Warnier [mailto:aw@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Recognizing certificate removal (SmartCard)
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
Posted by David kerber <dc...@verizon.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Recognizing certificate removal (SmartCard)
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
Posted by Will Nordmeyer <qu...@gmail.com>.
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-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: Recognizing certificate removal (SmartCard)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
Posted by Will Nordmeyer <qu...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Recognizing certificate removal (SmartCard)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org