tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Cain <>
Subject Re: Cert Lockdown - 3.3 Integration
Date Tue, 07 Aug 2001 07:57:45 GMT

You told me in the beginning that if I needed any additional callbacks to let 
you know. I think I do, and I'll explain why. If you think I'm on the wrong 
track, let me know.

Any arbitrary number of http interceptors can be defined (I think, right?), 
each with the ability to bind to a specific external interface (IP addresss). 
Any number of these can be secure, since the only real SSL limitation is the 
old "one cert per external address" rule. I therefore have only three options 
that I see:

1) Create some kind of new attribute for the Http connectors 
("promptForKeyPass" or something) and add the appropriate set() method to 
Http10Interceptor. This would basically negate the need for a separate module, 
but fiddling with Http10Interceptor == not at all tempting.

2) Create a new customer interceptor which loads at a higher level (server or 
context) and acts as a kind of "Http Connector Listener". Using the 
addInterceptor() callback, it would scan each interceptor loaded and check for 
secure Http10Interceptors (or, more specifically, for any secure instances of 
PoolTcpConnector), and call the prompt if necessary.

3) Create some kind of new child tag for the Http interceptors. I have no 
absolutely no idea how to implement this in the current architecture.

I already pretty much discounted #1 (unless for some reason you like it). #2, 
which I think would make sense as a child of <server>, has the benefit of a 
little cleaner config file and significantly cleaner code, at a slight cost to 
runtime performance. My implementation, which I had already started before #3 
occurred to me, would check each interceptor being loaded for "instanceof 
PoolTcpConnector.getClass()". If true, then it would check to see it if is 
secure. If, it would use the Feliner utility to prompt for the keystore 
password, then call the setKeysPass() method with the specified value. I'm not 
sure exactly what the performace hit would be for this design in a typical 
environment, but it probably wouldn't be that noticable.

If I go with #2, I will need a new callback. The addInterceptor() comments says 
that it is called before the new interceptor is initialized, which obviously 
wouldn't work for this scenerio. I'll need one that gives me a callback for 
_after_ the new interceptor is initialized, so that I can check to see if it is 
secure. There are therefore two remaining issues if I go with the second 

1) I need the new callback.
2) I need a new mechanism for checking whether or not the keystorePass was 
explicitly specified in the tag, since I will want to skip the prompt for those 
particular interceptors. I was thinking of simply adding a boolean field to the 
socket factory, isKeypassSet (or whatever), which would get toggled to true in 
the setKeysPass() method.


- Christopher

View raw message