hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf Hauser (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-498) Document how to limit available enabled ciphers AuthSSLProtocolSocketFactory and StrictSSLProtocolSocketFactory
Date Mon, 15 May 2006 20:08:06 GMT
    [ http://issues.apache.org/jira/browse/HTTPCLIENT-498?page=comments#action_12402403 ] 

Ralf Hauser commented on HTTPCLIENT-498:
----------------------------------------

BTW, if a server properly checks the FIN message, it should recognize that some ciphers didn't
reach the client because the hash over all previous messages would no longer be correct. Therefore,
the attack may not be all that easy...

> 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