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 20:26:14 GMT
I was thinking along the lines of:
interface SSLSupport {
  java.security.cert.Certificate[] getCertificateChain(Socket);
 String getCipherSuite(Socket);
 byte[] getSessionID(Socket);
}
and adding:
public abstract SSLSupport getSSLSupport();

to ServerSocketFactory.

This way DefaultServerSocketFactory (used by Ajpx and JNI) can simply return
null (or in j-t-c can use it implement lazy evaluation of SSL attributes).
----- Original Message -----
From: <cmanolache@yahoo.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>; "EKR"
<ekr@rtfm.com>
Cc: "Bill Barker" <william.barker@wilshire.com>; "jean-frederic clere"
<jfrederic.clere@fujitsu-siemens.com>
Sent: Wednesday, November 07, 2001 12:44 PM
Subject: Re: Tomcat to support other keystore types?


> On 7 Nov 2001, Eric Rescorla wrote:
>
> > Creation of SSL sockets will be the same as before (at least
> > for now [1]) : you'll specify an appropriate socketFactory and that
> > will create ServerSockets (which in turn will create Sockets).
> >
> > Each Socket created (transitively) by SSLSocketFactory must
> > implement interface SSLSocketExtensions. This will look something
> > like this:
> >
> > interface SSLSocketExtensions {
> > java.security.cert.Certificate[] getCertificateChain();
> > String getCipherSuite();
> > byte[] getSessionID();
> >
> > ... (more methods as required)
> > }
>
> This seems reasonable and it's an improvement over what we have.
>
> But I would prefer something like:
>
> interface SSLSupport {
> .....
> }
>
> And then the HTTP module will set a note/attribute on the request with a
> SSLSupport object ( which can be or wrap the socket object ), while Ajp
> will use it's own impl.
>
> This would allow the same code to be used for both Ajp and HTTP.
>
> Casting the socket doesn't make sense on Ajp ( and even less for JNI
> connector ). Moving the code that is dealing with SSL out of the HTTP
> adapter ( as much as possible ) would be very usefull.
>
> As implementation - the factory can either return a socket implementing
> the SSLSupport ( or a better named interface :-) or we can wrap the socket
> that is returned ( using JSSESSLSupport, etc ).
>
> > Then, all Tomcat code can just do (for instance):
> > java.security.cert.Certificate[] certs;
> >
> > certs=((SSLSocketExtensions)socket).getCertificateChain();
>
> > Does this seem acceptable?
>
> I don't like the last part ( casting the socket ), but it is acceptable.
>
> > [1] In the future we might wish to standardize interfaces to
> > the SocketFactory to permit standardized policy/configuration
> > information to be communicated.
>
> Again, I don't like the 'socket' part, I would prefer an abstraction
> that doesn't have anything to do with sockets.
>
> The code that deal with SSL should be independent of the SSL
> implementation - and if apache is doing the SSL side we might have no
> socket visible in tomcat.
>
> Costin
>
>
> --
> 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