Eric Rescorla wrote:
>
> <[EMAIL PROTECTED]> 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.
Does implAccept play something there?
>
> > 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){
> ssl=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.)
>
> -Ekr
>
> --
> [Eric Rescorla [EMAIL PROTECTED]]
> http://www.rtfm.com/
>
> --
> 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]>
