tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Rescorla <...@rtfm.com>
Subject Re: Tomcat to support other keystore types?
Date Wed, 07 Nov 2001 14:19:02 GMT
jean-frederic clere <jfrederic.clere@fujitsu-siemens.com> writes:

> Eric Rescorla wrote:
> > Currently CertCompat has JSSE hardwired in.
> 
> Due to:
> +++
>  static final String JSSE_SUPPORT=
>         "org.apache.tomcat.util.compat.JSSECertCompat";
> +++
Yep. Perhaps I should have said "dynamically hardwired :)"

> We just need "org.apache.tomcat.util.compat.PureTLSCertCompat" and a parameter
> to allow JSSE_SUPPORT to be changed in SSL_SUPPORT. Quick hack would be to add
> PureTLS_SUPPORT and try to load both classes the successfully one would be the
> one used.
This doesn't sound safe in the long run since it's possible you might
have both in your classpath but want to switch-hit based on a parameter.

> How could we add it as a parameter in the server.xml file?
This also seems dangerous since it runs the risk of the user getting
his settings mismatched (e.g. trying to use the PureTLS-compatible
certificate compatability layer with JSSE sockets). This problem will
get even worse if we have to introduce more compatibility classes
to expose other session properties such as negotiated ciphersuite.

My taste would be to have the user specify just one setting. Here
are at least two approached for doing this (there are of course others).

(1) Have all SSL sockets implement:

interface SSLImplementationParameters {
	string getImplementationName();
	string getCertCompatLayerName();
	string getOtherCompatLayerName();
	...
}

Then you could cast the socket to SSLImplementationParameters to
extract the name of the compatibility class from the socket.


(2) Instead of installing a socketfactory install an SSLImplementation:

interface SSLImplementation {
	string getImplementationName();
	string getSocketFactoryName();
	...
}

You could then interrogate the SSLImplementation to discover which
compatability class to use.


Yet another alternative would be to force all SSL modules to implement
o.a.t.?.SSLSocket. This class would offer all the API points that
Tomcat needed without having to use reflection to discover the
necessary bridging code. However, it seems like you've already decided
against this approach in favor of using explicit compatibility
layers.


-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message