Eric Rescorla wrote:
>
> As discussed on the list previously, I'm working on changing the SSL
> interfaces in Tomcat to make them more portable to various SSL
> toolkits, in particular PureTLS. In the process I've run into some
> issues that I wanted to run by the list.
>
> 1. I don't see how to make the switch-hit via a configuration file in
> 3.3. If you set the "secure" variable for your virtual server,
> PoolTCPConnector tries to load the class named in socketFactoryName,
> or, if null, the class named in SSL_FACT (currently JSSE). I've spent
> some time looking through the code and I don't see anything that
> would cause it to be set. Setting socketFactory in server.xml doesn't
> work. Have I missed something obvious or is this currently broken?
It works for me:
+++
<Http10Connector port="8080"
secure="false"
maxThreads="100"
maxSpareThreads="50"
minSpareThreads="10"
SocketFactory="toto" />
+++
And I got java.lang.ClassNotFoundException: toto as excepted.
>
> 2. Both JSSE and PureTLS derive almost all of their exceptions from
> IOException. If a server socket throws an IOException in accept() it
> will cause PoolTcpEndpoint.acceptSocket() to destroy the
> endpoint. This appears to be currently safe with JSSE because JSSE
> doesn't throw an exception when a handshake fails but instead returns
> a socket which throws an IOException when used.
>
> IMHO it's a mistake to rely on that behavior since it's kind of a
> misfeature in JSSE and this is already a problem with PureTLS, which
> does throw exceptions when the handshake fails. In the future Either
> PoolTcpEndpoint will have to be more forgiving or we'll need to wrap
> the socket so that it throws SocketException (which acceptSocket
> handles more cleanly).
>
> 3. Originally I'd intended to have ServerSockets return a class
> that subclassed SSLSupport. E.g.
>
> class PureTLSSSLSocket extends SSLSocket implements SSLSupport {
> ...
> }
>
> Unfortunately, as I should have seen immediately this isn't very
> convenient. There's no way to make JSSE return a programmer-specified
> subclass of SSLSocket instead of SSLSocket. I can of course make
> PureTLS do so but that ties it inappropriately to Tomcat.
>
> This leaves us with two alternatives:
> (1) Create a wrapper class for SSLSocket:
>
> class SSLSocketWrapper extends Socket implements SSLSupport {
> Socket internal;
>
> SSLSocketWrapper(Socket sock) {
> internal=sock;
> }
>
> // Forwarding for all the relevant socket methods
> }
>
> In general I hate class forwarding so I'm strongly tempted not to
> do this.
>
> (2) Extend/generalize the socketFactory to include an SSLSupport
> factory. This is actually pretty convenient since the relevant
> section of code, Http10Interceptor already has access to
> the socketFactory information via inheritance from
> PoolTcpConnector. This could be done in several ways
>
> (a) Require that all SocketFactorys that produce SSL sockets implement
>
> interface SSLSupportFactory {
> public SSLSupport createSSLSupport(Socket socket);
> }
>
> Then Http10Interceptor could do:
> if(secure) {
> SSLSupport sslSupport=((SSLSupportFactory)socketFactory)->
> createSSLSupport(socket);
>
> // Add the SSLSupport as a not
> }
>
> (b) Have a second factory object in PoolTcpConnector and use reflection
> to look it up. I don't much like this idea because it implies that
> you can mix and match SocketFactories with SSLSupport classes
> which of course you cannot.
>
> I'd like to hear comments about this stuff. :)
>
> -Ekr
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
