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?
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]>
