Loosen TLS config for pushy-server 1.x

[stevendanna]

Summary

Until opscode-push-jobs-server 2 is certified for use with Chef
Automate, supporting 1.x out of the box is essential.

To achieve compatibility, we need to add support for TLS 1.0 and an
older set of ciphers supported both by the older versions of erlang and
ruby that product ships.

Do we really need to change both the protocols and the cipher suite?

I believe so, below I've recorded my observations with other possible
changes.

Out of the box

Out of the box there are two points of failure I was able to
find:

1. API requests fail, producing the following error in the opscode-pushy
   erlang application:

   Webmachine error at path "/organizations/testorg/pushy/jobs" :
     {throw, {error,{conn_failed,{error,closed}}},
     [{file,"src/pushy_http_common.erl"},{line,44}]},
      {pushy_org,fetch_org_id,1,   [{file,"src/pushy_org.erl"},{line,38}]},
      {pushy_object,fetch_org_id,1,[{file,"src/pushy_object.erl"},{line,45}]},
      {pushy_wm_base,verify_request_signature,2,[{file,"src/pushy_wm_base.erl"},{line,157}]},
      {pushy_wm_base,is_authorized,2,[{file,"src/pushy_wm_base.erl"},{line,135}]},
      {webmachine_resource,resource_call,3,[{file,"src/webmachine_..."},...]},...]}
   

2. opscode-push-jobs-server-ctl test fails with the following error
   without making any requests to the pushy application:

   lib/pedant/core_ext/net_http.rb:61:in `connect':
   Connection reset by peer - SSL_connect (Errno::ECONNRESET)
   

ssl_ciphers only

If I add the following to chef-server.rb (newlines for readability):

nginx['ssl_ciphers'] =
"ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:
ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES256-GCM-SHA384:
AES:!aNULL:!eNULL:!EXPORT"

(Note this configuration adds AES to the ssl_ciphers)

We observe that:

• The erlang app fails with the same error as in the out-of-the-box case.

• opscode-push-jobs-server-ctl test fails with the same error as in
  the out-of-the-box case.

ssl_protocols modified to have TLSv1.1

If I add:

nginx['ssl_protocols'] = "TLSv1.1 TLSv1.2"

• The erlang app fails with the same error as in the out-of-the-box case.

• opscode-push-jobs-server-ctl test fails with the same error
  as in the out-of-the-box case.

If I further modify the pedant config as we did with reporting using either

ssl_version :TLSv1_1

or

ssl_version :TLSv1_2

opscode-push-jobs-server-ctl test continues to fail, but with an error
in the form of:

lib/pedant/core_ext/net_http.rb:37:in `ssl_version=':
unknown SSL method `TLSv1_1'. (ArgumentError)

The only ssl_verions supported by version of ruby shipping in reporting
seems to be TLSv1 or SSLv3.

ssl_protocols modified to have TLSv1

If I add:

nginx['ssl_protocols'] = "TLSv1 TLSv1.1 TLSv1.2"

• The erlang application fails with a new error:

  SSL: hello: ssl_connection.erl:1724:Fatal error: handshake failure
  Webmachine error at path "/organizations/testorg/pushy/jobs" :
  {throw,{error,{conn_failed,{error,esslconnect}}},
    [{pushy_http_common,fetch_authenticated,2,[{file,"src/pushy_http_common.erl"},{line,44}]},
     {pushy_org,fetch_org_id,1,[{file,"src/pushy_org.erl"},{line,38}]},
     {pushy_object,fetch_org_id,1,[{file,"src/pushy_object.erl"},{line,45}]},
     {pushy_wm_base,verify_request_signature,2,[{file,"src/pushy_wm_base.erl"},{line,157}]},
     {pushy_wm_base,is_authorized,2,[{file,"src/pushy_wm_base.erl"},{line,135}]},
     {webmachine_resource,resource_call,3,[{file,"src/webmac..."},...]},...]}
  

• opscode-push-jobs-server-ctl test fails with the a new error:

  lib/pedant/core_ext/net_http.rb:61:in `connect':
  SSL_connect returned=1 errno=0 state=SSLv3 read server hello A: sslv3 alert handshake failure
  

It is only when I apply both the changes to ssl_protocol and ssl_ciphers
that both the erlang application and pedant works.

Signed-off-by: Steven Danna [email protected]

[stevendanna]

cc @jeremiahsnapp @chef/chef-server-maintainers

[danielsdeleo]

What does TLS1 mean, exactly? Can we just allow TLSv1.1? Why do we need both?

[stevendanna]

We need TLSv1 which I believe means TLS 1.0 because that is all the version of ruby we ship in pushy 1.x understands, at least in the experiments I did.

[marcparadise]

Have we verified that the cipher change alone isn't enough?

[stevendanna]

We need the protocol change if we want the pedant tests to work.

[stevendanna]

@marcparadise @danielsdeleo I've updated the commit message and the PR message with a bunch of my observations when testing this. I believe they point to both changes definitely being needed. I think there is probably a more restrictive ciphersuite we can add other than AES but per in-person feedback we weren't sure it made sense to spend a lot of time finding one. But if anyone has a recommendation, I can apply it.

[markan]

👍 I think this is the right choice for now; especially if we document how to tighten things up for those who don't need push 1.x support.

[danielsdeleo]

Let's make reverting this part of the work of updating push jobs 1.x, though