You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Ken Krugler <kk...@transpac.com> on 2015/09/07 20:06:03 UTC
Input on solution for "Could not generate DH keypair" error w/SSL connection
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
--------------------------
Ken Krugler
+1 530-210-6378
http://www.scaleunlimited.com
custom big data solutions & training
Hadoop, Cascading, Cassandra & Solr
Re: Input on solution for "Could not generate DH keypair" error w/SSL connection
Posted by Ryan Fulghum <ry...@gmail.com>.
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ø" <st...@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-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
>
>
> --
> BEKK Open
> http://open.bekk.no
>
> TesTcl - a unit test framework for iRules
> http://testcl.com
>
Re: Input on solution for "Could not generate DH keypair" error w/SSL connection
Posted by Stefan Magnus Landrø <st...@gmail.com>.
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-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
--
BEKK Open
http://open.bekk.no
TesTcl - a unit test framework for iRules
http://testcl.com
Re: Input on solution for "Could not generate DH keypair" error
w/SSL connection
Posted by 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-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org