Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Could not generate DH keypair #2872

Closed
lephyrius opened this issue Apr 24, 2015 · 9 comments
Closed

Could not generate DH keypair #2872

lephyrius opened this issue Apr 24, 2015 · 9 comments
Labels
openssl
Milestone
Invalid or Duplicate

Comments

@lephyrius
Copy link

I'm using:
jruby 1.7.19 (2.0.0p598) 2015-01-29 20786bd on Java HotSpot(TM) 64-Bit Server VM 1.8.0-b132 +jit [darwin-x86_64]
I inserted this code into IRB:

require 'net/http'
Net::HTTP.get(URI('https://rails-assets.org/'))

I got this error:

Java::JavaLang::RuntimeException: Could not generate DH keypair
    from sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1362)
    from sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:529)
    from sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:807)
    from sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:775)
    from javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
    from org.jruby.ext.openssl.SSLSocket.readAndUnwrap(SSLSocket.java:550)
    from org.jruby.ext.openssl.SSLSocket.doHandshake(SSLSocket.java:430)
    from org.jruby.ext.openssl.SSLSocket.connectCommon(SSLSocket.java:203)
    from org.jruby.ext.openssl.SSLSocket.connect(SSLSocket.java:180)
    from org.jruby.ext.openssl.SSLSocket$INVOKER$i$0$0$connect.call(SSLSocket$INVOKER$i$0$0$connect.gen)
    from org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:134)
    from org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:60)
    from org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
    from org.jruby.evaluator.ASTInterpreter.INTERPRET_BLOCK(ASTInterpreter.java:112)
    from org.jruby.runtime.Interpreted19Block.evalBlockBody(Interpreted19Block.java:206)
    from org.jruby.runtime.Interpreted19Block.yield(Interpreted19Block.java:157)
... 197 levels...
    from org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
    from org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)
    from org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:182)
    from org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:203)
    from org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:326)
    from org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:170)
    from Users..$_dot_rbenv.versions.jruby_minus_1_dot_7_dot_19.bin.irb.__file__(.rbenv/versions/jruby-1.7.19/bin/irb:13)
    from Users..$_dot_rbenv.versions.jruby_minus_1_dot_7_dot_19.bin.irb.load(.rbenv/versions/jruby-1.7.19/bin/irb)
    from org.jruby.Ruby.runScript(Ruby.java:866)
    from org.jruby.Ruby.runScript(Ruby.java:859)
    from org.jruby.Ruby.runNormally(Ruby.java:728)
    from org.jruby.Ruby.runFromMain(Ruby.java:577)
    from org.jruby.Main.doRunFromMain(Main.java:395)
    from org.jruby.Main.internalRun(Main.java:290)
    from org.jruby.Main.run(Main.java:217)
    from org.jruby.Main.main(Main.java:197)

This is problematic if you got rails-assets in the bundler gemfile.
rubygems/bundler#3588
@kares
Copy link
Member

kares commented Apr 28, 2015

unfortunately it seems specific to your ENV/OS ... could you maybe try updating Java (I'm not sure what your version 1.8.0-b132 means) ... here's how it rolls on Linux (Ubuntu) :

jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) 64-Bit Server VM 1.8.0_45-b14 +jit [linux-amd64]

jruby-1.7.19 :001 > require 'net/http'
 => true 
jruby-1.7.19 :002 > Net::HTTP.get(URI('https://rails-assets.org/'))
 => "<html>\r\n<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>400 Bad Request</h1></center>\r\n<center>The plain HTTP request was sent to HTTPS port</center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n" 


jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) 64-Bit Server VM 1.7.0_72-b14 +jit [linux-amd64]

jruby-1.7.19 :001 > require 'net/http'
 => true 
jruby-1.7.19 :002 > Net::HTTP.get(URI('https://rails-assets.org/'))
 => "<html>\r\n<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>400 Bad Request</h1></center>\r\n<center>The plain HTTP request was sent to HTTPS port</center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"

... you could also try updating OpenSSL to its latest gem install jruby-openssl

@kares kares added the openssl label Apr 28, 2015
@lephyrius
Copy link
Author

Looks like you are using 1.9.3 .
I used: 2.0
So try running:
jruby --2.0 -S irb

It works perfectly for me in "jruby --1.9 -S irb" .

@headius
Copy link
Member

headius commented Apr 29, 2015

@tarcieri just reported this to the rails-assets.org folks. He believes their form of DH is not supported by the JVM, and the best option would probably be to just ditch DH.

@tarcieri
Copy link

Yeah, the root cause is their external ciphersuite is using 4096-bit Diffie-Hellman, and the highest supported by the JVM is 1024-bit. However, even having Diffie-Hellman in your ciphersuite at all makes no sense, because elliptic curve Diffie-Hellman (i.e. ECDHE) is both faster and widely supported.

I told them to shut off Diffie-Hellman entirely, which should fix the problem.

@mrbrdo
Copy link
Contributor

mrbrdo commented May 27, 2015

Since today I started getting this error from the mixpanel-ruby client as well, it is due to a change they made to their server SSL config.

For now I disabled using DHE in Java:

java.security.Security.setProperty("jdk.tls.disabledAlgorithms", "SSLv3, DHE")

It seems this must be done before any HTTPS requests are made.

@tarcieri
Copy link

That change was probably motivated by the recent Logjam attack:

https://weakdh.org/

Unfortunately, instead of switching to the faster, more modern and more secure ECDHE, several sites seem to be increasing DHE keystrength.

IMO DHE should just be disabled. Cryptographer Matt Green said the same thing:

http://blog.cryptographyengineering.com/

In short, probably the best long-term move is to switch to elliptic curves (ECDHE) as soon as possible.

@tarcieri
Copy link

Note that rubygems.org just changed their external ciphersuite, and now RubyGems is broken for all JRuby users 😭

@headius you should probably just shut off DHE entirely so this stops happening using the workaround @mrbrdo suggested

@mrbrdo
Copy link
Contributor

mrbrdo commented May 31, 2015

oh god 😒

@tarcieri
Copy link

I got the RubyGems people to roll back, but I'm guessing this is going to be a bigger and bigger problem, especially as the Logjam attack is getting people to try to tune up their D-H parameters:

https://weakdh.org/

@enebo enebo added this to the Invalid or Duplicate milestone Jun 10, 2015
@jamestalmage jamestalmage mentioned this issue Oct 21, 2015
Closed
@jkutner jkutner mentioned this issue May 10, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
openssl
Projects
None yet
Milestone
Invalid or Duplicate
Development

No branches or pull requests
6 participants
@tarcieri @headius @enebo @kares @mrbrdo @lephyrius