We did the same thing in our Android app to remove unwanted Ciphers. We queried for enabled cipher suites in prepareSocket() and evicted the unwanted. On Sep 8, 2015 09:36, "Stefan Magnus Landrø" <stefan.lan...@gmail.com> wrote:
> I fully agree. Hardening ssl config both client and server side makes a lot > of sense. Most folks focus on the server config, but client config is > equally important. > > Stefan > > 2015-09-08 10:20 GMT+02:00 Oleg Kalnichevski <ol...@apache.org>: > > > On Mon, 2015-09-07 at 11:06 -0700, Ken Krugler wrote: > > > Hi there, > > > > > > Some background first… > > > > > > I was using a fairly old version of HttpClient (4.2.5) to access some > > Wikipedia pages, and started getting SSLPeerUnverifiedException errors > > while connecting. > > > > > > One change was that Wikipedia recently started only supporting https > > connections - see > > > http://venturebeat.com/2015/06/12/wikipedia-to-start-using-secure-https-by-default-for-all-users/ > > > > > > But getting details on what was going wrong was challenging - enabling > > HTTP wire logging didn't show me much useful information. > > > > > > Once I enabled SSL Handshake debug via the Java VM parameter > > -Djavax.net.debug=ssl:handshake, I could see that the error was "Could > not > > generate DH keypair" > > > > > > I then followed the second suggestion at > > > http://stackoverflow.com/questions/10687200/java-7-and-could-not-generate-dh-keypair > , > > which involves getting rid of ciphers that cause problems with Java 7. > > > > > > Here's my modified SSLSocketFactory (and yes, for 4.3 or later I should > > be using SSLConnectionSocketFactory)... > > > > > > private static class MySSLSocketFactory extends SSLSocketFactory { > > > > > > public MySSLSocketFactory(SSLContext sslContext) { > > > super(sslContext); > > > } > > > > > > @Override > > > protected void prepareSocket(SSLSocket socket) throws > > IOException { > > > super.prepareSocket(socket); > > > > > > String[] enabledCipherSuites = > > socket.getEnabledCipherSuites(); > > > > > > // avoid hardcoding a new list, we just remove the entries > > > // which cause the exception > > > List<String> asList = new > > ArrayList<String>(Arrays.asList(enabledCipherSuites)); > > > > > > // See > > > http://stackoverflow.com/questions/10687200/java-7-and-could-not-generate-dh-keypair > > > // we identified the following entries causing the problems > > > // "Could not generate DH keypair" > > > // and "Caused by: > > java.security.InvalidAlgorithmParameterException: Prime size must be > > multiple of 64, and can only range from 512 to 1024 (inclusive)" > > > asList.remove("TLS_DHE_RSA_WITH_AES_128_CBC_SHA"); > > > asList.remove("SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA"); > > > asList.remove("TLS_DHE_RSA_WITH_AES_256_CBC_SHA"); > > > > > > socket.setEnabledCipherSuites(asList.toArray(new > > String[asList.size()])); > > > } > > > } > > > > > > This seems to be working fine, but it feels like a hack to remove > > specific ciphers. > > > > > > Is there a better (more robust) solution? Should this only be used if > an > > un-hacked try fails with this kind of problem? > > > > > > Thanks, > > > > > > -- Ken > > > > Hi Ken > > > > I see nothing hacky about this solution. Restricting ciphers enabled for > > a particular SSL session looks like a normal thing to do. > > > > Oleg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > -- > BEKK Open > http://open.bekk.no > > TesTcl - a unit test framework for iRules > http://testcl.com >
