'[jira] Resolved: (HTTPCLIENT-498) Document how to limit available'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    [jira] Resolved: (HTTPCLIENT-498) Document how to limit available
From:       "Oleg Kalnichevski (JIRA)" <jira () apache ! org>
Date:       2008-11-26 13:02:44
Message-ID: 223109479.1227704564294.JavaMail.jira () brutus
[Download RAW message or body]


     [ 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


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic