You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apps-dev@avalon.apache.org by Greg Steuck <gr...@nest.cx> on 2002/09/14 02:16:32 UTC
TLSSocketFactory
Hello,
I am going to use TLSSocketFactory in my application and I would like
to discuss some changes I am about to make and see how folks feel
about them.
First, I am going to improve the javadocs:
* move the configuration description to the top of the class
(and replace those nasty <> with char entities)
* specify the defaults for the configuration keys
* maybe produce a schema file for the configuration (low priority
for me plus I don't know xml schema syntax)
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.
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.
So how does the above sound?
Thanks
Greg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TLSSocketFactory
Posted by Peter Donald <pe...@apache.org>.
On Sat, 21 Sep 2002 11:29, Greg Steuck wrote:
> Did you have a chance to take a look at that TLSSocketFactory stuff I
> sent? Anything I should change before the changes can be committed?
Just looking at it now. I am going to kill a protected variable but other than
that it all looks good. Hopefully I will commit it today ;)
--
Cheers,
Peter Donald
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TLSSocketFactory
Posted by Greg Steuck <gr...@nest.cx>.
Hi Peter,
Did you have a chance to take a look at that TLSSocketFactory stuff I
sent? Anything I should change before the changes can be committed?
Thanks
Greg
P.S. Previous message was cut off by my experiments with Gnus. I
hope this message gets through uncorrupted and with the correct
from address for this list.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TLSSocketFactory
Posted by Greg Steuck <gr...@nest.cx>.
Hi Peter,
Did you have a chance to take a look at that TLSSocketFactory stuff I
sent? Anything I should change befor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TLSSocketFactory
Posted by Greg Steuck <gr...@nest.cx>.
>>>>> "Peter" == Peter Donald <pe...@apache.org> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TLSSocketFactory progress
Posted by Peter Donald <pe...@apache.org>.
On Wed, 18 Sep 2002 00:56, Greg Steuck wrote:
> Doh, I guess my mail client stripped my comment from the message with
> sources. It wasn't HTML, I just don't know enough of Gnus to properly
> use messages with attachments, so VM it is.
Well they came through to me when I moderated your mail but by the time they
got to list they got stripped... not sure where or why if it wasn't html ..
;/
BTW you are sending from a different address than which are subscribed with
which may explain delays you see.
--
Cheers,
Peter Donald
-----------------------------------------------------
When a stupid man is doing something he's ashamed of,
he always declares that it is his duty.
George Bernard Shaw
-----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TLSSocketFactory progress
Posted by Greg Steuck <gr...@nest.cx>.
Doh, I guess my mail client stripped my comment from the message with
sources. It wasn't HTML, I just don't know enough of Gnus to properly
use messages with attachments, so VM it is.
>>>>> "Peter" == Peter Donald <pe...@apache.org> writes:
Peter> Looks good ... however I would recomend that you migrate the
Peter> static methods to some utility class if you can (or at least
Peter> make them private).
So private they will be. They were part of a utility class up until 4pm
yesteday when I decided that it could be a separate component that we
would reuse in both factories.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TLSSocketFactory progress
Posted by Peter Donald <pe...@apache.org>.
Looks good ... however I would recomend that you migrate the static methods to
some utility class if you can (or at least make them private).
BTW HTML gets stripped from these mailing lists ;)
--
Cheers,
Peter Donald
Sufficiently advanced science is
indistinguishable from magic"
-- Arthur C. Clarke
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
TLSSocketFactory progress
Posted by Greg Steuck <gr...@nest.cx>.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
TLSSocketFactory.initSocket
Posted by Greg Steuck <gr...@nest.cx>.
I took a closer look at TLSSocketFactory.initSocket method which is
called for all created sockets. I don't like what it does.
private Socket initSocket( final Socket SSLSocket )
{
// Enable all available cipher suites when the socket is connected
final String[] cipherSuites = sslSocket.getSupportedCipherSuites();
sslSocket.setEnabledCipherSuites( cipherSuites );
}
This enables all cipher suites behind the scene. This may have
devastating effect on communications confidentiality. Here's the list of
ciphers that get added by Sun's JSSE when all supported ciphers are
enabled (java full version "1.4.0_01-b03")
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
None of the above give me warm fuzzies. Quoting openssl ciphers man
page:
eNULL, NULL
the "NULL" ciphers that is those offering no
encryption. Because these offer no encryption at all
and are a security risk they are disabled unless
explicitly included.
aNULL
the cipher suites offering no authentication. This is
currently the anonymous DH algorithms. These cipher
suites are vulnerable to a "man in the middle" attack
and so their use is normally discouraged.
The right course of action is to make the ciphers configurable. Yet, I
don't have a pressing need to do that for my application. So, how would
you folks react if the code above simply disappears as insecure and the
sockets are created with default ciphers until somebody will go ahead
and add the appropriate configuration option?
Thanks
Greg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: phoenix-blocks doesn't like '\u' (unicode quoted) characters
Posted by Greg Steuck <gr...@nest.cx>.
>>>>> "Peter" == Peter Donald <pe...@apache.org> writes:
Peter> Hmm - Looks like a bug wrt xdoclets parser. Do you want to
Peter> add a bug report to their site (xdoclet.sourceforge.net) ?
Nah, they already know about it:
http://sourceforge.net/tracker/?group_id=31602&atid=402704&func=detail&aid=535982
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: phoenix-blocks doesn't like '\u' (unicode quoted) characters
Posted by Peter Donald <pe...@apache.org>.
Hmm - Looks like a bug wrt xdoclets parser. Do you want to add a bug report to
their site (xdoclet.sourceforge.net) ?
On Wed, 18 Sep 2002 06:14, Greg Steuck wrote:
> Here is a piece of valid java code that phoenix-blocks barfs on:
>
> Arrays.fill( passChars, '\u0000' );
>
> [phoenix-blocks] Error parsing
> /home/greg/work/avalon/cornerstone/src/java/org/apache/avalon/cornerstone/b
>locks/sockets/SSLFactoryBuilder.java:Lexical error at line 190, column 39.
> Encountered: "u" (117), after : "\'\\"
>
> Javac compiles that code just fine.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
phoenix-blocks doesn't like '\u' (unicode quoted) characters
Posted by Greg Steuck <gr...@nest.cx>.
Here is a piece of valid java code that phoenix-blocks barfs on:
Arrays.fill( passChars, '\u0000' );
[phoenix-blocks] Error parsing /home/greg/work/avalon/cornerstone/src/java/org/apache/avalon/cornerstone/blocks/sockets/SSLFactoryBuilder.java:Lexical error at line 190, column 39. Encountered: "u" (117), after : "\'\\"
Javac compiles that code just fine.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TLSSocketFactory
Posted by Peter Donald <pe...@apache.org>.
Hi Greg,
On Sat, 14 Sep 2002 10:16, Greg Steuck wrote:
> I am going to use TLSSocketFactory in my application and I would like
> to discuss some changes I am about to make and see how folks feel
> about them.
great.
> First, I am going to improve the javadocs:
> * move the configuration description to the top of the class
> (and replace those nasty <> with char entities)
yay!
> * specify the defaults for the configuration keys
yay!
> * maybe produce a schema file for the configuration (low priority
> for me plus I don't know xml schema syntax)
yay! yay!
> 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.
hmm .. not sure either ... I vaguely remember there was a reason for this but
it seems fairly silly now ... ANy one else got any ideas?
> 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.
works for me.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>