Use TLSv1 handshake when connecting to the server #119

Closed
wants to merge 1 commit into
from

Projects

None yet

2 participants

@joerocklin

I've been following the instructions for building your own multi-node PaaS. rhc commands on the broker work just fune, but when trying to connect remotely I got an error about the connection failing due to an SSL error. This sets the SSL protocol to TLSv1, which allows connections without error.

@smarterclayton
Member

Thanks for bringing this up - I think this highlights an area of concern, in that the gem isn't taking advantage of the system infrastructure by default to verify the SSL connection. There are 3 kind of scenarios for a CLI.

  1. trusted well known server (openshift.redhat.com) that has a well known public cert
  2. trusted local/private server that has a cert that can be imported into the local system config (when you're running on the local node)
  3. untrusted local/private test server where SSL verification is irrelevant, but where the client isn't on the same system

Your case sounds like #3 for now, but with #2 there will be a need to ensure that the cert store is checked on connection if you want to prevent MITM attacks. We should probably also allow a config/CLI flag to disable checking (just like curl).

@smarterclayton
Member

The TLS version can also be different between servers running Origin, so we can't simply disable / set it (for instance there may be restrictive firewalls that require TLSv1+

@joerocklin

I might also be interested in a 4th option of:

Trusted local/private server that has a cert that can be imported into the local system config when the client isn't on the same system.

That is: I have a self-signed cert that is used for internal purposes and I have the CA available locally on the system, but the client is not running on the broker.

Looking into the rest-client methods, it would appear that there are ways of setting the various certificate options and ssl_verification options for the net-http object, but not the ssl_version. There is an open pull request for the rest-client to add this, though the project seems to be less-than-responsive over the last few months.

Perhaps some extra values in the express.conf file should be added to support the extra ssl options?

@smarterclayton
Member

Sounds like that's really the only option. We're rapidly removing the old broker calls (J5's commits are all around replacing those with a newer command structure), so in the next few months we should be solely calling the rest_client.

Being able to init the rest_client with the config object correctly, grabbing a set of defaults for SSL (although I imagine converting the constants is a bit tricky) but allowing override, and then possibly an --insecure global config flag to allow the client to bypass client verification altogether is a good idea.

We don't quite have the full infrastructure to support it, but also ideally any SSL client errors would be caught and handled appropriately so people can figure out what is going on.

@smarterclayton
Member

After a very, very, very long delay, I'm finally going through and attempting to address SSL auth from the CLI in a comprehensive way. https://github.com/smarterclayton/rhc/compare/refactor_rhc_rest_client has the beginnings of the changes - there is an --ssl-version commit in place, as well as support for --insecure.

All of the standard net::http ssl options will be available via the CLI and settable into the config file. rhc setup will only warn about insecure.

Will mark this as closed when the pull is ready.

@smarterclayton
Member

The vast majority of necessary changes are in https://github.com/smarterclayton/rhc/tree/use_nahi_httpclient_instead. I switched to http client, but the 2.2 version that ships with rhel doesn't allow ssl-version to be passed to OpenSSL. As soon as we get a new version in the EPEL pipeline ill bump the minimum version to 2.3.1, which will complete the support.

See 'rhc help options' for the supported options.

@smarterclayton
Member

This is now fixed in #274

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment