tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Rescorla <>
Subject Re: Portable SSL Support
Date Tue, 13 Nov 2001 17:19:35 GMT
<> writes:
> Setting the socketFactory can force one behavior or another, but for
> 'regular' users it should be possible to just set secure and the code
> to detect what is available and use it.
I can do this.

> > 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).
> One simple workaround could be to abstract acceptSocket() too ( i.e. make
> it a method in ServerSocketFactory or SSLSupport).
Yes, we could do that. It's a little ugly but it avoids having a wrapper
class around ServerSocket so I suppose it's worthwhile.

> A don't like this either ( and I didn't like too much the idea
> of returning a socket that implements SSLSupport either ).
> What I would do is:
> SSLSupport {
>    String getFoo( Object socket, ... );
> }
This makes me very nervous since the first thing you have to do is
a downcast. I hate downcasts. (Except when I love them :)

> - PoolTcpConnector will just have a method 'setSSLSupport'
> - SSLSupport will be an abstract class, and will contain code to do
> reflection and create the exact implementation
> - Code using SSL will call SSLSupport.getSSLSupport() ( and maybe
> setProperty, etc ), then set it on PoolTcpConnector ( if sockets are
> used), etc.
> - SSLSupport should be independent of tomcat ( you may noticed that
> tomcat.util is compiled without any other tomcat class in classpath,
> i.e. it can't have any dependencies on any internal tomcat class ! )
Hmm... This seems like a kind of confusing merging of internal and
external interfaces. (The internal ones being the ones required to
create the socket factories and the external ones being those required to
manipulate the SSL data.)

I'm (more than) happy to replace SSLFactory at the external interface but 
I don't like merging SSLSupport into the external class. So, using
another layer of abstraction.

interface SSLSupport {
	 public String getCipherSuite();

abstract class SSLImplementation {
	static getInstance(); // Automatically picks out whatever there is
	static getInstance(String classname); // gets a specific instance

	SocketFactory getSocketFactory();
	SSLSupport getSSLSupport(Socket sock);

class JSSEImplementation extends SSLImplementation {

class PureTLSImplementation extends SSLImplementation {

In general I'd expect SSLSupport to be implemented as a wrapper class.
E.g. a prototype PureTLSSSLSupport would be:

class PureTLSSSLSupport implements SSLSupport {
        SSLSocket ssl;

	PureTLSSSLSupport(SSLSocket s){

	public string getCipherSuite() {
	  int cipherSuite=ssl.getCipherSuite();
	  return SSLPolicyInt.getCipherSuiteame(cipherSuite);


Then the user can either do "secure" or "secure" and "SSLImplementation=blah".

> BTW, my personal preference is to avoid too many interfaces - in general I
> prefer abstract classes if it is possible.
I have some of the same taste as well, but I want to use an interface for
SSLSupport to allow the possibility of not having wrapper classes
in some situations. 

That said, having lots of interfaces does seem to be the Java way, no?
(Worse yet, I've been switching back and forth between Java and C++ so
I suffer from idiom inertia.)


[Eric Rescorla                         ]

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

View raw message