tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r616522 - in /tomcat/trunk/java/org/apache/tomcat/util/net/puretls:
Date Wed, 30 Jan 2008 20:31:47 GMT
Filip Hanik - Dev Lists wrote:
> Bill Barker wrote:
>> I'm for removing support for PureTLS, since it is largely unmaintained 
>> at the moment.  But the abstraction is usefull to be able to support 
>> SSL providers (e.g. Mozilla meantioned above) that don't implement 
>> JSSE.  It wasn't about getting removing it from the NIO Connecter, 
>> just making the signature not depend on JSSE.  So for JSSE, something 
>> like:
>>    public SSLSupport getNioSSLSupport(Socket sock) {
>>          return factory.getSSLSupport(((SSLSocket)sock).getSession());
>>   }
> I guess what I'm confused about is the signature change and the name of 
> the method.
> With NIO there is no such thing as an SSLSocket, but the method name 
> indicates that the method is used only for NIO.
> With NIO you have access to the SSLSession, through the SSLEngine. The 
> concept of SSLSocket doesn't exist, since the encryption/decryption 
> happens outside of the realm of sockets.

There appears to be general agreement on removing the TLS stuff. I'll get 
that done.

Re the abstraction, I have done some background reading and our current 
socket based SSL abstraction just won't work for NIO.

Option 1 is to provide an NIO compatible transport independent SSL 
abstraction, an implementation of the abstraction using JSSE and re-write 
the NIO (and possibly the BIO) connector to use it. However, this would be 
a lot of work for little gain.

Given that the NIO connector is hard coded to use JSSE anyway, options 2 is 
to modify the NIO connector to go straight to the JSSE implementation, 
bypassing the abstraction. That would enable the JSSE specific code to be 
removed from the abstraction, allowing other non-JSSE socket based SSL 
implementations for the BIO connector should anyone feel so inclined. At a 
later point if someone has an itch to implement option 1 then there would 
be nothing stopping them.

I'll start working up a patch - it should be simple. Thoughts?


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

View raw message