Accessing Vault via Curl on CentOS 6.6

[Clay Bowen]

We use CentOS 6.6 and RedHat 6.6 on our production servers (this is not up to me), and the base distribution of these servers have an older version of Curl (7.19) that doesn't appear to support the protocol used by Vault (NSS error -12190).  There doesn't appear to be a way to ask Vault to lower it's framework to TLS1.1 or add other (older) encryption methods than TLS_RSA_WITH_AES_128_CBC_SHA.  

I need a way to access Vault on these servers or I will have to discontinue development.  I can install updates / packages to increase the version of Curl / OpenSSL / or NSS, but I'm having difficulty finding a repo that contains appropriate versions for these systems (they are all running GLibC 2.12).

Any help would be appreciated.

Thanks,

Clay

curl -v -X PUT --cert "./test.pem" https://10.16.19.21:8000/v1/auth/cert/login|awk -F, '{print $5}'|awk -F: '{print $3}'|sed 's/"//g'

* About to connect() to 10.16.19.21 port 8000 (#0)

*   Trying 10.16.19.21... connected

* Connected to 10.16.19.21 (10.16.19.21) port 8000 (#0)

* Initializing NSS with certpath: sql:/etc/pki/nssdb

*   CAfile: /etc/pki/tls/certs/ca-bundle.crt

  CApath: none

* NSS error -12190

* Error in TLS handshake, trying SSLv3...

> PUT /v1/auth/cert/login HTTP/1.1

> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2

> Host: 10.16.19.21:8000

> Accept: */*

>

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connection died, retrying a fresh connect

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Closing connection #0

* Issue another request to this URL: 'https://10.16.19.21:8000/v1/auth/cert/login'

* About to connect() to 10.16.19.21 port 8000 (#0)

*   Trying 10.16.19.21... connected

* Connected to 10.16.19.21 (10.16.19.21) port 8000 (#0)

* TLS disabled due to previous handshake failure

*   CAfile: /etc/pki/tls/certs/ca-bundle.crt

  CApath: none

* NSS error -12190

* Closing connection #0

* SSL connect error

[Justin LaRose]

Had the same issue here: https://groups.google.com/d/topic/vault-tool/4mTKh_bJXB0/discussion

I tried building from source a later version of curl and openssl but didn't have any success running CentOS. I'm hoping someone has better success than me. 

[Clay Bowen]

Yeah I hope so - this tool has a lot of functionality we could really use, but if I can't run it on our production systems...  Considering how large the base of systems running Linux 6, keeping Vault this constrained just seems a little silly.  TLS 1.1 isn't THAT much less secure than TLS 1.2, and by allowing Vault to be configured to accept TLS 1.1 it would widen the machines capable of using it by about 90%

Clay

[Armon Dadgar]

Hey Clay,

Please file a ticket for this. We can support this as a configurable flag. Our goal is to always

use the most conservative and secure defaults where possible, so that users don’t have to worry

the default configurations. That said, we need knobs to enable/disable things where they

make sense like this.

Best Regards,

Armon Dadgar

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/8998a70d-6a28-443d-9d33-4a0955f4bbf1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeff Mitchell]

You can also change this locally as a workaround until there is a
flag; look around line 113 in command/meta.go. Look for
'tls.VersionTLS12' and change to 'tls.VersionTLS11' or
'tls.VersionTLS10' as appropriate, then build Vault.

--Jeff

> https://groups.google.com/d/msgid/vault-tool/etPan.55a700bd.4e6afb66.6c5d%40Armons-MacBook-Air.local.

[Jeff Mitchell]

Also you will have to change it at command/server/listener.go around
line 56...look for the line 'tlsConf.MinVersion = tls.VersionTLS12'
and change it as appropriate.

--Jeff

[Clay Bowen]

I had to drop the version to TLS1.0 (VersionTLS10), but it's now working with the linux 6.6 systems.

I created a branch, made the change, compiled and tested with cnark.  Here's the result:

[root@ip-10-16-43-125 ~]# ./cnark.pl -h 10.16.19.21 -p 8000 -i

CryptoNark v0.5.6 running on linux

Testing SSLv2 Ciphers...

Testing SSLv3 Ciphers...

Testing TLSv1 Ciphers...

    ECDHE-RSA-AES256-SHA -- 256 bits, High Encryption, Forward Secrecy

    AES256-SHA -- 256 bits, High Encryption

    ECDHE-RSA-DES-CBC3-SHA -- 168 bits, High Encryption, Forward Secrecy

    DES-CBC3-SHA -- 168 bits, High Encryption

    ECDHE-RSA-AES128-SHA -- 128 bits, High Encryption, Forward Secrecy

    ECDHE-RSA-RC4-SHA -- 128 bits, High Encryption, Forward Secrecy

    AES128-SHA -- 128 bits, High Encryption

    RC4-SHA -- 128 bits, Medium Encryption

Testing TLSv1.2 Ciphers...

    ECDHE-RSA-AES128-GCM-SHA256 -- 128 bits, High Encryption, Forward Secrecy

It would be nice (although I know it's a lot more work) to limit the ciphers (at least removing RC4-SHA, which IMHO is pretty insecure).  But it works, which is 100% better than yesterday so I'm not complaining.

Thanks,

Clay

[Jeff Mitchell]

Hi Clay,

Part of the point of standardizing on TLS 1.2 in the first place is to limit insecure cipher suites. Since you are custom compiling with an older TLS version you'll also need to lock down cipher suites on your own.

You can do this in the same locations as before in the same tls.Config struct with the CipherSuites parameter. See https://golang.org/pkg/crypto/tls/#pkg-constants

--Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/d4d23695-1381-4182-99b5-e3028e4b1190%40googlegroups.com.

[Clay Bowen]

Thanks a lot -- this is likely a temporary solution for me as I intend to write the connection code (this is a prototype) but we all know how often the prototype becomes the production.  I mentioned the cipher because the team was discussing adding a flag to allow the drop to TLS1.0 to support older clients.  The post was suggesting that when that flag is implemented, the cipher suite should probably be limited at the same time so as to keep as much security as possible while still allowing access.

I have been successful in accessing Vault from several Linux 6 systems since I branched the code to allow TLS1.0 -- I've tested RedHat, CentOS, Scientific Linux, and Ubuntu.  

Thanks!

Clay

[Aaron Salvo]

I've run into this exact problem. 

It was solved by building the latest version of curl.

On thing to note when you do a make install for curl: it installs into /usr/local/bin. 

Which doesn't appear to be the standard install location for curl on CentOS. I ended up with multiple versions on my systems.

On Wednesday, July 15, 2015 at 12:50:28 PM UTC-4, Clay Bowen wrote:

[Clay Bowen]

I tried the latest version of Curl available through the CentOS 6.6 and SciLinux 6.6 repos and they didn't support the cipher used by Vault.  I took care of the problem, though, by writing a quick program in Go.  Maybe it'll help anyone else with this problem (note - I'm a total neophyte with Go):

package main

import (

 "fmt"

 "strings"

 "crypto/tls"

 "net/http"

)

func main () {

  cert, err := tls.LoadX509KeyPair("./test.pem", "./test.pem")  // First is cert, second is key - I have both combined in the file

  if err != nil {

    fmt.Println("Error %s",err)

  }

  config := tls.Config{Certificates: []tls.Certificate{cert}, InsecureSkipVerify: true}

  transport := &http.Transport{

     TLSClientConfig: &config,

  }

  client := http.Client{Transport: transport}

  resp, err := client.Post("https://10.16.19.21:8000/v1/auth/cert/login", "application/json",nil)

  defer resp.Body.Close()

  if err != nil {

     fmt.Println("Error: %s",err)

  }

  token := strings.Split(resp.Header["Set-Cookie"][0],";")

  fmt.Println(token[0][6:len(token[0])])

}

I cut our some of the parts not needed by a general audience, but this should be pretty close.  Since it's written in Go, it supports the same version & cipher as used in the Vault program.  You can tweak this to use a different authentication back-end, take parameters for locations, etc.  

Thanks,

Clay

[Wayne Walker]

I also saw this problem.  I built the 7.29 version of curl from CentOS 7:

wget http://mirror.centos.org/centos-7/7/updates/x86_64/Packages/openssl-1.0.1e-42.el7.9.x86_64.rpm
yum install         krb5-devel        libidn-devel        libssh2-devel        nss-devel        openldap-devel        stunnel        zlib-devel        valgrind perl-Time-HiRes
rpmbuild --rebuild curl-7.29.0-19.el7.src.rpm

... and it still failed ...

Then I added --tlsv1.2 to the curl command, and now it works.  :-)

Thank you all for doing the original work to narrow the problem.

Wayne

[Michael Fischer]

Fortunately this should only be a temporary workaround.  The next Vault release will allow connections from clients built with older OpenSSL libraries that don't have TLS 1.2 support (i.e. EL 6, Ubuntu 12) by setting 'tls_min_version' to 'tls10' in the listener config.

Unfortunately this option was added to the public documentation too soon; it doesn't work in the current release. See https://github.com/hashicorp/vault/pull/531

--Michael

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/c46f61b2-19b0-47b7-85e9-ea6ea908f0de%40googlegroups.com.

[Clay Bowen]

Michael, I'm using that option in my test system right now - it's working for me.  I'm running Vault v0.2.1-dev (cd6c3f0712db19da1a6538db472d22c9fc6d601e) on my test system. 

Here is a CNARK printout for my test system, then my production system:

Test:

CryptoNark v0.5.6 running on linux

Testing SSLv2 Ciphers...

Testing SSLv3 Ciphers...

Testing TLSv1 Ciphers...

    ECDHE-RSA-AES256-SHA -- 256 bits, High Encryption, Forward Secrecy

    AES256-SHA -- 256 bits, High Encryption

    ECDHE-RSA-DES-CBC3-SHA -- 168 bits, High Encryption, Forward Secrecy

    DES-CBC3-SHA -- 168 bits, High Encryption

    ECDHE-RSA-AES128-SHA -- 128 bits, High Encryption, Forward Secrecy

    ECDHE-RSA-RC4-SHA -- 128 bits, High Encryption, Forward Secrecy

    AES128-SHA -- 128 bits, High Encryption

    RC4-SHA -- 128 bits, Medium Encryption

Testing TLSv1.2 Ciphers...

    ECDHE-RSA-AES128-GCM-SHA256 -- 128 bits, High Encryption, Forward Secrecy

Production:

CryptoNark v0.5.6 running on linux

Testing SSLv2 Ciphers...

Testing SSLv3 Ciphers...

Testing TLSv1 Ciphers...

Testing TLSv1.2 Ciphers...

    ECDHE-RSA-AES128-GCM-SHA256 -- 128 bits, High Encryption, Forward Secrecy

Here's my test system's config:

backend "consul" {

  address = "consul.company.com:8500"

  advertise_addr = "http://10.16.19.21:8000"

  path = "vault"

}

listener "tcp" {

  address = "10.16.19.21:8000"

  tls_cert_file = "/root/selfsigned.crt"

  tls_key_file = "/root/selfsigned.key"

  tls_min_version = "tls10"

}

disable_mlock = true

Thanks,

Clay