tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: Tomcat to support other keystore types?
Date Wed, 07 Nov 2001 16:46:59 GMT
Eric Rescorla wrote:
> 
> 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.

So we need a org.apache.catalina.net.SSLSocket in TC4.x and
org.apache.tomcat.util.net.SSLSocket.

> 
> (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.

How do you get the SocketFactory in the Socket?

> 
> 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.

Sounds better than actual implementation :)

> However, it seems like you've already decided
> against this approach in favor of using explicit compatibility
> layers.

Somes patches + Votes may change decisions...


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

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