hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HTTPCLIENT-498) Document how to limit available enabled ciphers AuthSSLProtocolSocketFactory and StrictSSLProtocolSocketFactory
Date Mon, 15 May 2006 19:13:07 GMT
     [ http://issues.apache.org/jira/browse/HTTPCLIENT-498?page=all ]

Oleg Kalnichevski updated HTTPCLIENT-498:
-----------------------------------------

    Component: HttpConn
                   (was: HttpClient)

> Document how to limit available enabled ciphers AuthSSLProtocolSocketFactory and StrictSSLProtocolSocketFactory
> ---------------------------------------------------------------------------------------------------------------
>
>          Key: HTTPCLIENT-498
>          URL: http://issues.apache.org/jira/browse/HTTPCLIENT-498
>      Project: HttpComponents HttpClient
>         Type: Improvement

>   Components: HttpConn
>     Versions: Nightly Builds
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Ralf Hauser
>     Assignee: HttpClient Dev
>     Priority: Minor
>      Fix For: 4.0 Final

>
> Another Man-in-the-Middle attack is to alter the cipherlists exchanged during
> the SSL handshake. Often servers are not properly configured and due to lack of
> "Secure By Default" (Another Man-in-the-Middle attack is to alter the cipherlists exchanged
during
> the SSL handshake. Often servers are not properly configured and due to lack of
> "Secure By Default" (Bug 35765) weak 40 bit export ciphers or even null-ciphers
> can be forced upon the participants without them really noticing.
> Sure, this should primarily be in the server's responsibility, but since we
> often cannot control what server admins are doing, the prudent thing to do to
> protect your own https connections it to ensure that at least the client under
> your control watches out for this.
> I have built my own implementation extending javax.net.ssl.SSLSocketFactory that
> lets me control the String[] enabledCipherSuites of each socket created.
> However, I don't really see how I could bring that to fruition without foregoing
> or duplicating all the virtues of AuthSSLProtocolSocketFactory and
> StrictSSLProtocolSocketFactory. If this is possible, please document, otherwise
> I suggest to enhance the class in order to be able to do so.
> Just FYI, take my favourite paypal.com - a quick analysis with the tool in
> http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1162 reveals that they
> for example are susceptible to that attack:
> SSL_CK_DES_192_EDE3_CBC_WITH_MD5 supported
> SSL_CK_DES_64_CBC_WITH_MD5 supported
> SSL_CK_IDEA_128_CBC_WITH_MD5 supported
> SSL_CK_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 supported
> SSL_CK_RC2_CBC_128_CBC_WITH_MD5 supported
> SSL_CK_RC4_128_EXPORT40_WITH_MD5 supported
> SSL_CK_RC4_128_WITH_MD5 supported
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA supported
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA supported
> SSL_DHE_RSA_WITH_DES_CBC_SHA supported
> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA supported
> SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 supported
> SSL_RSA_EXPORT_WITH_RC4_40_MD5 supported
> SSL_RSA_WITH_3DES_EDE_CBC_SHA supported
> SSL_RSA_WITH_DES_CBC_SHA supported
> SSL_RSA_WITH_IDEA_CBC_SHA supported
> SSL_RSA_WITH_RC4_128_MD5 supported
> SSL_RSA_WITH_RC4_128_SHA supported
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA supported
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA supported
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA supported
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA supported
> TLS_DHE_RSA_WITH_DES_CBC_SHA supported
> TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA supported
> TLS_RSA_EXPORT1024_WITH_RC4_56_SHA supported
> TLS_RSA_EXPORT_WITH_DES40_CBC_SHA supported
> TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 supported
> TLS_RSA_EXPORT_WITH_RC4_40_MD5 supported
> TLS_RSA_WITH_3DES_EDE_CBC_SHA supported
> TLS_RSA_WITH_AES_128_CBC_SHA supported
> TLS_RSA_WITH_AES_256_CBC_SHA supported
> TLS_RSA_WITH_DES_CBC_SHA supported
> TLS_RSA_WITH_IDEA_CBC_SHA supported
> TLS_RSA_WITH_RC4_128_MD5 supported
> see also Bug 19218 (perhaps this idea might have some merit after all)) weak 40 bit export
ciphers or even null-ciphers
> can be forced upon the participants without them really noticing.
> Sure, this should primarily be in the server's responsibility, but since we
> often cannot control what server admins are doing, the prudent thing to do to
> protect your own https connections it to ensure that at least the client under
> your control watches out for this.
> I have built my own implementation extending javax.net.ssl.SSLSocketFactory that
> lets me control the String[] enabledCipherSuites of each socket created.
> However, I don't really see how I could bring that to fruition without foregoing
> or duplicating all the virtues of AuthSSLProtocolSocketFactory and
> StrictSSLProtocolSocketFactory. If this is possible, please document, otherwise
> I suggest to enhance the class in order to be able to do so.
> Just FYI, take my favourite paypal.com - a quick analysis with the tool in
> http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1162 reveals that they
> for example are susceptible to that attack:
> SSL_CK_DES_192_EDE3_CBC_WITH_MD5 supported
> SSL_CK_DES_64_CBC_WITH_MD5 supported
> SSL_CK_IDEA_128_CBC_WITH_MD5 supported
> SSL_CK_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 supported
> SSL_CK_RC2_CBC_128_CBC_WITH_MD5 supported
> SSL_CK_RC4_128_EXPORT40_WITH_MD5 supported
> SSL_CK_RC4_128_WITH_MD5 supported
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA supported
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA supported
> SSL_DHE_RSA_WITH_DES_CBC_SHA supported
> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA supported
> SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 supported
> SSL_RSA_EXPORT_WITH_RC4_40_MD5 supported
> SSL_RSA_WITH_3DES_EDE_CBC_SHA supported
> SSL_RSA_WITH_DES_CBC_SHA supported
> SSL_RSA_WITH_IDEA_CBC_SHA supported
> SSL_RSA_WITH_RC4_128_MD5 supported
> SSL_RSA_WITH_RC4_128_SHA supported
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA supported
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA supported
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA supported
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA supported
> TLS_DHE_RSA_WITH_DES_CBC_SHA supported
> TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA supported
> TLS_RSA_EXPORT1024_WITH_RC4_56_SHA supported
> TLS_RSA_EXPORT_WITH_DES40_CBC_SHA supported
> TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 supported
> TLS_RSA_EXPORT_WITH_RC4_40_MD5 supported
> TLS_RSA_WITH_3DES_EDE_CBC_SHA supported
> TLS_RSA_WITH_AES_128_CBC_SHA supported
> TLS_RSA_WITH_AES_256_CBC_SHA supported
> TLS_RSA_WITH_DES_CBC_SHA supported
> TLS_RSA_WITH_IDEA_CBC_SHA supported
> TLS_RSA_WITH_RC4_128_MD5 supported
> see also HTTPCLIENT-194 (perhaps this idea might have some merit after all)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message