[
https://issues.apache.org/jira/browse/HTTPCLIENT-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550103
]
Ralf Hauser commented on HTTPCLIENT-498:
----------------------------------------
see also HTTPCLIENT-710
> Document how to limit available enabled ciphers AuthSSLProtocolSocketFactory
> and StrictSSLProtocolSocketFactory
> ---------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-498
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-498
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpConn
> Affects Versions: Snapshot
> Environment: Operating System: other
> Platform: Other
> Reporter: Ralf Hauser
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
