TLSSocketFactory.initSocket

[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>