>>>>> "Peter" == Peter Donald <[EMAIL PROTECTED]> writes:
>> * maybe produce a schema file for the configuration (low priority
>> for me plus I don't know xml schema syntax)
Peter> yay! yay!
I thought about it again. I don't see how that can be done:
TLSSocketFactory is not a block. Moreover, I don't quite understand how
configuration schema for DefaultSocketManager could work. The problem is
it embeds all kinds of factories and they may have any kind of
configuration. The worst part: they all are "factory" elements inside
the socket manager, and only their class name determines what kind of
configuration they will be using. What am I missing?
>> Then, I don't see how authenticate-client is applicable to the
>> _client_ connections this factory produces. So I propose to
>> remove this notion altogether from the class.
Peter> hmm .. not sure either ... I vaguely remember there was a
Peter> reason for this but it seems fairly silly now ... ANy one
Peter> else got any ideas?
On a somewhat related note, I am going to add a configuration option
which would force verification of the server Common Name against the
hostname the connection was established to. This will make these sockets
behave similarly to web browser. I don't feel like checking certificate
validity dates at the moment though.
>> Finally, TLSSocketFactory has 3 public overloaded createSocket
>> methods allowing one to wrap an existing socket into SSL. The
>> problem with that is that these methods are not part of
>> SocketFactory service. The methods themselves are genuinely
>> useful, so I propose an extension of SocketFactory that specifies
>> them and then we can have TLSSocketFactory provide both services.
Peter> works for me.
I thought about this for a while, and even started implementing it, but
realized that these allegedly useful methods are not that useful at all.
Besides the 2 utility methods that are better put into some utility
class there is a single useful method in TLSSocketFactory:
/**
* Returns a socket layered over an existing socket connected to
* the named host, at the given port. This constructor can be used
* when tunneling SSL through a proxy or when negotiating the use
* of SSL over an existing socket. The host and port refer to the
* logical peer destination. This socket is configured using the
* socket options established for this factory.
*
* @param s - the existing socket
* @param host - the server host
* @param port - the server port
* @param autoClose - close the underlying socket when this socket is closed
*
* @exception IOException - if the connection can't be established
* @exception UnknownHostException - if the host is not known
*/
public Socket createSocket( Socket s, String host, int port, boolean
autoClose ) throws IOException
My conclusion after reading the javadoc above is: this is a kind of low
level stuff that is best hidden behind SocketFactory interface. So, if
you really need a socket that is established through a proxy you just
write MyProxyTLSSocketFactory, you don't have your clients do that.
So, my current intention is to remove those three methods from
TLSSocketFactory altogether and add that server host name verification
feature. Objections? Thoughts?
Thanks
Greg
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
