Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <50BF738F.9070601@christopherschultz.net>
Date: Wed, 05 Dec 2012 11:17:19 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Recognizing certificate removal (SmartCard)
References: 
 <CAN=ruA4unuWSZ0887GTWAoPy9sm9emQtnLGZ760YiU_1-oMOVQ@mail.gmail.com>
 <50BE36E8.7000500@christopherschultz.net>
 <50BE3774.6090904@christopherschultz.net>
 <CAN=ruA5h93z5shGdsJZo6dtYpVvRx8Qfg479PbEyZ9TC7njSGg@mail.gmail.com>
 <50BE5815.2050809@christopherschultz.net>
 <CAN=ruA7okWepSoUW5UPk7WuPk-go5DsuENV1jgrNz1o_OzK_XA@mail.gmail.com>
In-Reply-To: 
 <CAN=ruA7okWepSoUW5UPk7WuPk-go5DsuENV1jgrNz1o_OzK_XA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----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 
> <chris@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