Curl {"errors":["tls connection required"]}

[Clay Bowen]

I'm getting this error now (I wasn't prior to last week) when attempting to use CURL to get a token using CERTIFICATE authentication.

Here's the command line I'm using:

curl -v -X PUT --cert "/root/Tester.pem" https://10.16.19.21:8000/v1/auth/cert/login

and the result:

*   Trying 10.16.19.21...

* 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: client certificate from file

*       subject: CN=*,O=,L=,ST=,C=US

*       start date: Jun 24 17:41:57 2015 GMT

*       expire date: Jun 23 17:41:57 2016 GMT

*       common name: *

*       issuer: CN=*,O=,L=,ST=,C=US

* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA

* Server certificate:

*       subject: CN=*,O=,L=,ST=,C=US

*       start date: Jun 04 20:11:19 2015 GMT

*       expire date: Oct 19 20:11:19 2042 GMT

*       common name: *

*       issuer: CN=*,O=,L=,ST=,C=US

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

> User-Agent: curl/7.40.0

> Host: 10.16.19.21:8000

> Accept: */*

>

< HTTP/1.1 400 Bad Request

< Content-Type: application/json

< Date: Wed, 08 Jul 2015 18:52:23 GMT

< Content-Length: 39

<

{"errors":["tls connection required"]}

* Connection #0 to host 10.16.19.21 left intact

I've tried with --tlsv1.2 with the same result.  Using --tlsv1.1 or --tlsv1.0 get's an unsupported error.  I'm using CentOS 6.6 with all current updates from the Amazon default update server, as most of the clients we run use this for updates.  If I have to have something special (not in current distribution libraries for RedHat or CentOS) then I won't be able to get authorization to use Vault on corporate servers.  Maybe I just messed something up?

Thanks,
Clay

[Jeff Mitchell]

Hi Clay,

Can you comment on what may have changed on the system? Most
importantly, did you change the version of Vault?

If you're building Vault from source, you may want to try a build from
a week or two ago and see if it's still working. If it does, and if
you want to be super helpful, you could try using "git bisect" to
pinpoint the commit with which this stopped working.

--Jeff

> --
> 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/74c07aba-8997-4249-aae4-5c7c99a39175%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Clay Bowen]

Ran CNARK and it reports no connection on SSL1, SSL2, SSL3, TLS1.1 and only one cipher accepted on TLS1.2

[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...

Testing TLSv1.2 Ciphers...

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

Thanks,

Clay

[Clay Bowen]

Hey Jeff, yes I build from source frequently.  As you can see from the post above, it appears that Vault only accepts a very small pool of TLS certifications (one, actually), and only TLS v1.2.  That will affect a number of older clients.  I know that connection security is important, but if it's impossible for the clients to pass proper authentication data due to the highly restrictive connection parameters... well, you get the picture.  More ciphers and TLS 1.1 would be appreciated (TLS 1.1 is still fairly secure).  You can probably skip SSL as most security folks won't allow that anymore anyway.  Or better yet, provide a way for administrators to configure what protocols will be accepted on their vault instance.

Thanks,

Clay

[Jeff Mitchell]

Hi Clay,

Since you are building from source, and since you say this was working
earlier, it would be useful if you can identify when this stopped
working. Any chance you can git bisect? Since it was working a week
ago it shouldn't take very long.

Thanks,
Jeff

> --
> 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/635542f4-5e6b-4aed-b9de-68a48a7fac8d%40googlegroups.com.

[Clay Bowen]

Yeah, I'll get build from older and see if I can find the build where it was added.  

I found more information, though - I tested the only cipher allowed specifically.

[root@ip-10-16-43-125 ~]#  curl --cipher ecdhe_rsa_aes_128_gcm_sha_256 -v -X PUT --cert "/root/scripts.crt" --key "/root/scripts.key" https://10.16.19.21:8000/v1/auth/cert/login

*   Trying 10.16.19.21...

* 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: client certificate from file

*       subject: CN=Scripts,OU=Development,O=,L=,ST=,C=US

*       start date: Jun 04 15:32:01 2015 GMT

*       expire date: Jul 04 15:32:01 2015 GMT

*       common name: Scripts

*       issuer: CN=Scripts,OU=Development,O=,L=,ST=,C=US

* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

* Server certificate:

*       subject: CN=*,O=,L=,ST=,C=US

*       start date: Jun 04 20:11:19 2015 GMT

*       expire date: Oct 19 20:11:19 2042 GMT

*       common name: *

*       issuer: CN=*,O=,L=,ST=,C=US

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

> User-Agent: curl/7.40.0

> Host: 10.16.19.21:8000

> Accept: */*

>

< HTTP/1.1 400 Bad Request

< Content-Type: application/json

< Date: Wed, 08 Jul 2015 20:18:49 GMT

< Content-Length: 39

<

{"errors":["tls connection required"]}

* Connection #0 to host 10.16.19.21 left intact

Note that I still get an error, even specifying the cipher.  Now let me test that I'm actually using the cipher correctly:

[root@ip-10-16-43-125 ~]#  curl --cipher ecdhe_rsa_aes_128_gcm_sha_256 -v https://www.howsmyssl.com/a/check

*   Trying 54.214.40.84...

* Connected to www.howsmyssl.com (54.214.40.84) port 443 (#0)

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

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

  CApath: none

* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

* Server certificate:

*       subject: CN=howsmyssl.com,O=Darkish Green,L=San Francisco,ST=California,C=US

*       start date: Dec 31 00:00:00 2013 GMT

*       expire date: Dec 31 23:59:59 2015 GMT

*       common name: howsmyssl.com

*       issuer: CN=GeoTrust SSL CA - G2,O=GeoTrust Inc.,C=US

> GET /a/check HTTP/1.1

> User-Agent: curl/7.40.0

> Host: www.howsmyssl.com

> Accept: */*

>

< HTTP/1.1 200 OK

< Content-Length: 341

< Access-Control-Allow-Origin: *

< Connection: close

< Content-Type: application/json

< Date: Wed, 08 Jul 2015 20:20:49 GMT

< Strict-Transport-Security: max-age=631138519; includeSubdomains; preload

<

* Closing connection 0

{"given_cipher_suites":["TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"],"ephemeral_keys_supported":true,"session_ticket_supported":false,"tls_compression_supported":false,"unknown_cipher_suite_supported":false,"beast_vuln":false,"able_to_detect_n_minus_one_splitting":false,"insecure_cipher_suites":{},"tls_version":"TLS 1.2","rating":"Improvable"}

It's OK.  The server isn't accepting the only cipher it allows.

Thanks,

Clay

[Armon Dadgar]

Hey Clay,

Do you have any audit backends enabled? This may be a regression for 0.2.0rc.

Best Regards,

Armon Dadgar

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/7be3ba26-b82b-4a6c-90b4-cfe808664ae2%40googlegroups.com.

[Clay Bowen]

OK, here's what I found.  If I have AUDIT enabled (which was fixed some time ago), I get the tls error.  If I disable AUDIT, it works fine.

I ran back to the point before where audit was fixed, or 111856a00fe2a976c0814f519e18ed8bad3dc4b5, and it works.  Of course I had to disable audit or I get the earlier failure.  I then updated to current and it worked.  Once I enabled AUDIT again, it failed.  I haven't gotten the bisect done (I was finding an earlier version that worked), but now you have a bit more in case you want to start looking at it tonight.

Thanks,

Clay

[Armon Dadgar]

Hey Clay,

I just pushed b8754e7 to master, which should fix this issue. Could you please give that a shot?

Thanks for reporting this!

Best Regards,

Armon Dadgar

From: Clay Bowen <on.rode...@gmail.com>
Reply: vault...@googlegroups.com <vault...@googlegroups.com>>
Date: July 8, 2015 at 3:07:26 PM
To: vault...@googlegroups.com <vault...@googlegroups.com>>
Subject:  Re: [vault] Re: Curl {"errors":["tls connection required"]}

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/cb05d31c-757c-40b9-8e62-e9c171a52fea%40googlegroups.com.

[Clay Bowen]

I just fetched/compiled/tested the update - all is working now, both with and without auditing enabled.  Thanks a lot Armon!

Clay