Puma: SSL Error with self-signed certificate in dev when using Chrome 70

[eric-norcross]

Steps to reproduce

• Setup a dev environment on macOS 10.14.1
• Setup and configure a self-signed certificate
• Try to connect with Chrome 70

Expected behavior

It should connect with Chrome 70

Actual behavior

Puma throws the error: SSL error, peer: 127.0.0.1, peer cert: , #<Puma::MiniSSL::SSLError: OpenSSL error: error:141F7065:SSL routines:final_key_share:no suitable key share - 337604709>

When attempting to connect on Chrome 70, Chrome shows the following error

When accessing https://localhost:8080 on FireFox 63.0 (64-bit) I'm prompted to add a one-time security exception in order connect. Safari Version 12.0.1 has no issue connecting.

System configuration

• ruby 2.5.3
• rails 5.1.6
• puma 3.12.0
• macOS 10.14.1
• Chrome Version 70.0.3538.77 (Official Build) (64-bit)
• I've created a self-signed certificate following the Heroku instructions here
• I have the following in my hosts file:

    127.0.0.1   localhost
    255.255.255.255 broadcasthost
    ::1             localhost
    127.0.0.1 localhost.ssl

• Added the self-signed certificate to my system keychain and always trusted it
• In my puma config file, i'm starting puma with: ssl_bind '127.0.0.1', '8080', { key: 'localhost_ssl/server.key', cert: 'localhost_ssl/server.crt', verify_mode: 'none' }

I've also added an issue in Chrome bug tracker

[davidben]

Looks like the issue is this line here:
https://github.com/puma/puma/blob/72882f2319e65b371e1458069723279b3196a220/ext/puma_http11/mini_ssl.c#L193

P-521 is not a very common curve. It's not supported by Chrome or Edge. Prior to TLS 1.3, this was non-fatal but resulted in less secure settings. Starting TLS 1.3, enabled by default in OpenSSL 1.1.1, ECDH is mandatory. The immediate fix would be to use NID_X9_62_prime256v1 (P-256) instead, which is where most hardening work is focused.

But OpenSSL also has a fine set of defaults in 1.1.0, and an API to negotiate multiple curves. 1.0.2's defaults are a little large, but also fine. Thus, something like this may be better:

#if OPENSSL_VERSION_NUMBER < 0x10002000L
  // Remove this case if OpenSSL 1.0.1 (now EOL) support is no
  // longer needed.
  EC_KEY *ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
  if (ecdh) {
    SSL_CTX_set_tmp_ecdh(ctx, ecdh);
    EC_KEY_free(ecdh);
  }
#elif OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)
  // Prior to OpenSSL 1.1.0, servers must manually enable server-side ECDH
  // negotiation.
  SSL_CTX_set_ecdh_auto(ctx, 1);
#endif

[eric-norcross]

Given that this issue is related to the use of the P-521 curve, I'm curious how is this still working with Puma in Production on Heroku without issue? Does Heroku Automated Certificate Management somehow circumvent this?

Using puma 3.12.0 in Production on heroku-16 stack, I'm seeing the following from the Chrome security tab:

[davidben]

I suppose whatever that is running is using something else for TLS than the code snippet I found. Likely Heroku has a TLS terminator of its own.

(This would not be a property of the certificate. It's the TLS server configuration.)

[davidben]

(You would not get that output from Chrome if the linked code were running. Those calls tell OpenSSL to only support P-521, and you're getting P-256 out.)

[eric-norcross]

Thanks, I put in a support request with Heroku and point them to this thread. I'm hoping they can elaborate on how the Production server is configured so I can mirror that in Dev.

I Really appreciate your help in figuring this out!

[davidben]

No, what you want to do is make the code change I mentioned above.

[MSP-Greg]

@davidben

Thanks for your patch. Just ran it in my fork, and Travis (OpenSSL 1.0.1 thru 1.1.0) and Appveyor (OpenSSL 1.0.2 thru 1.1.1) all passed. I don't recall the test suite that well, but green is certainly good...

I guess BoringSSL people are as nice as the OpenSSL people. Thanks again, Greg

@eric-norcross if you don't want to submit a PR, I can do it tonite or tomorrow.

[eric-norcross]

@MSP-Greg I just implemented it in my fork and all tests passed for me as well. That being said, I'm a bit at a loss on how to write a test for this change. Any suggestions?

[dachinat]

Hi, is there a temporary fix until this PR will be merged? Thanks

[biznickman]

@dachinat if you are developing locally for now, I've used this line in my Gemfile and it fixed it until they merge:

gem 'puma', git: 'https://github.com/eric-norcross/puma.git', branch: 'chrome_70_ssl_curve_compatiblity'

[eric-norcross]

@biznickman I also ended up having to recreate my self-signed certificate, making sure to add Subject Alternate Name (SAN) support: https://ksearch.wordpress.com/2017/08/22/generate-and-import-a-self-signed-ssl-certificate-on-mac-osx-sierra/

[dachinat]

@biznickman @eric-norcross thanks!

[victorbucutea]

@biznickman @eric-norcross I tried the above solution and chrome works, safari on the other hand doesn't ...

[avdept]

Getting same issue while trying to access to local https via ngrok

[martingalovic]

Solved it: Brew uninstall & installed puma,
Then double-clicked on ~/Library/Application Support/io.puma.dev/cert.pem and selected Always Trust

[roccoblues]

Any updates on this? This is a pretty serious issue that's not only happening on MacOS. I have the same problem on Linux with Chrome 72.

There's a fix available for merge (https://github.com/puma/puma/pull/1671) that has been written by some pretty smart people here: https://bugs.chromium.org/p/chromium/issues/detail?id=899994#c8

[evanphx]

Should be fixed with the above PR.

[JackWells]

I encountered the same problem with Firefox in the "60s" versions (different machines, different versions, different OSes, same problem). Older versions of FF had no problems, but the newer versions would sometimes generate an error, sometimes time-out (no error in console), and sometimes work.

This version of the puma-gem solved the Firefox problem. Big Thanks to whoever did the work on it - using:
gem 'puma', git: 'https://github.com/eric-norcross/puma.git', branch: 'chrome_70_ssl_curve_compatiblity'

[MSP-Greg]

See Puma commit fc97fdaa

'Implemented NID_X9_62_prime256v1 (P-256) curve over P-521 in order to support Chrome 70 and Edge', by @eric-norcross...

[siddhant-mohan]

not working even with the master branch.

[inDDev]

Still have to use a branch as of Oct 2019.

gem 'puma', git: 'https://github.com/eric-norcross/puma.git', branch: 'chrome_70_ssl_curve_compatiblity'

Chrome Version 76.0.3809.132

[victorbucutea]

Same issue here

[dentarg]

How are people creating their self-signed certificate? How does the Puma config look?

I tried myself, using https://github.com/FiloSottile/mkcert, and I get no error from Puma when accessing via Chrome (or any other User-Agent)

[jeremywohl]

@dentarg The issue is that Rails, even as of Rails 6, is using the Puma v3 series. Luckily, the next Rails release will use v4.

@nateberkopec Perhaps another v3 point release, to include this patch, for all the pre-Rails 6.1 folks?

[nateberkopec]

@jeremywohl That's just the Rails project gemfile. You can use any version of Puma with any version of Rails.

[jeremywohl]

@nateberkopec Understood. But it took me some time to arrive at the upshot: oh, Rails defaults to an old version, missing some logic mkcert and other tools now expect.

So it can be a continuing, esoteric frustration to a block of nameless users, or magically get fixed in the next bundle update (for minor versions). My 2 cents. Thanks for your efforts.

[nateberkopec]

I get it. But maintaining multiple versions of Puma really increases the maintainer workload of this project. If Rails' new project template points to an old release series, my position is that you should just fix it in your own Gemfile.

[composerinteralia]

For what it's worth, the next Rails release will default to ~> 4.1 in the generated Gemfile instead of ~> 3.11 (see https://github.com/rails/rails/commit/2a3f759eef10352bedce5f13b12dbdda30aacab2).

[nateberkopec]

Fixed in v4.