tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: svn commit: r616522 - in /tomcat/trunk/java/org/apache/tomcat/util/net/puretls: PureTLSImplementation.java PureTLSSocket.java PureTLSSocketFactory.java PureTLSSupport.java
Date Wed, 30 Jan 2008 21:06:41 GMT
Mark Thomas wrote:
> 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?
yes, have it go to JSSE directly, I doubt that will change anytime soon 
anyway.

Filip
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message