tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Tomcat to support other keystore types?
Date Wed, 07 Nov 2001 18:21:46 GMT
I was leaning towards (1) personally, so that it could be checked in
conjunction with the "issecure" attribute.  The o.a.t.util.compat.* works
well when there are two choices, but not as well when you are trying to
create a plugability layer.


----- Original Message -----
From: "Eric Rescorla" <ekr@rtfm.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Cc: <jfrederic.clere@fujitsu-siemens.com>
Sent: Wednesday, November 07, 2001 6:19 AM
Subject: Re: Tomcat to support other keystore types?


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


*----*

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

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