You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2008/11/26 14:02:44 UTC
[jira] Resolved: (HTTPCLIENT-498) Document how to limit available
enabled ciphers AuthSSLProtocolSocketFactory and
StrictSSLProtocolSocketFactory
[ https://issues.apache.org/jira/browse/HTTPCLIENT-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-498.
------------------------------------------
Resolution: Won't Fix
Fix Version/s: (was: 4.0 Final)
The Zorg principle still applies: "If you want something done, do it yourself. Yep!"
http://www.imdb.com/title/tt0119116/quotes
Oleg
> 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
>
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org