tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Tomcat to support other keystore types?
Date Wed, 07 Nov 2001 20:44:10 GMT
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 {
>[] 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):
>[] 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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message