Using https connections

[george....@gmail.com]

Hello,

I have a small cluster with three virtual machines running rqlited secured with different self signed certificates and basic auth as the following:

        $HOME/bin/rqlited -auth auth.json -http-addr 10.10.180.61:4001 -raft-addr 10.10.180.61:4002 -http-cert server.crt -http-key server.key -node-encrypt -node-cert server.crt -node-key server.key -http-no-verify ~/node.1 > /tmp/node.1.log

        $HOME/bin/rqlited -http-addr 10.10.180.62:4001 -raft-addr 10.10.180.62:4002  -http-cert server.crt -http-key server.key -node-encrypt -node-cert server.crt -node-key server.key -http-no-verify -join https://root:12...@10.10.180.61:4001 ~/node.2 > /tmp/node.2.log

        $HOME/bin/rqlited -http-addr 10.10.180.63:4001 -raft-addr 10.10.180.63:4002  -http-cert server.crt -http-key server.key -node-encrypt -node-cert server.crt -node-key server.key -http-no-verify -join https://root:12...@10.10.180.61:4001 ~/node.3 > /tmp/node.3.log

The things works but I have the following issue, when I try to query other node than the leader the redirection return the redirected link always as http and not as https as I expected. 

        curl --location-trusted -u root:1234 --insecure -vsGL 'https://10.10.180.62:4001/db/query?pretty&timings' --data-urlencode 'q=SELECT * FROM foo'

The relevant part of the response is:

        * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

        * Mark bundle as not supporting multiuse

        < HTTP/1.1 301 Moved Permanently

        < Content-Type: application/json; charset=utf-8

        < Location: http://10.10.180.61:4001/db/query?pretty&timings&q=SELECT%20%2A%20FROM%20foo

        < X-Rqlite-Version: 5

        < Date: Wed, 23 Sep 2020 04:36:01 GMT

        < Content-Length: 0

This also seems to affect the rqlite console, eg: 

        ubuntu@node1:~$ rqlite -i -s https -H 10.10.180.62 -u root:1234

        Welcome to the rqlite CLI. Enter ".help" for usage hints.

        10.10.180.62:4001> .tables

        ERR! server responded with: 400 Bad Request

        10.10.180.62:4001> 

 

Thanks.

[Philip O'Toole]

Hmmm, I think this might be an oversight when it comes to what the nodes respond and how the CLI deals with it. The nodes always do the right thing (they have more information) but the CLI is not doing the right thing, as you can/

I'll see if I can fix this ASAP, and get back to you.

--
You received this message because you are subscribed to the Google Groups "rqlite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rqlite+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rqlite/e9fafcdf-f4c4-45af-bacb-184837d6e126n%40googlegroups.com.

[Philip O'Toole]

I've just released a new version, v5.4.1, which I think will fix the issue. Can you try the latest release, and let me know?

https://github.com/rqlite/rqlite/blob/master/CHANGELOG.md

[george....@gmail.com]

I've tested and redirection works for https connections but something seems to be broken now for http connections. I used this configuration:

    $HOME/bin/rqlited -http-addr 10.10.180.61:4001 -raft-addr 10.10.180.61:4002 ~/node.1 > /tmp/node.1.log

    $HOME/bin/rqlited -http-addr 10.10.180.62:4001 -raft-addr 10.10.180.62:4002 -join http://10.10.180.61:4001 ~/node.2 > /tmp/node.2.log

    $HOME/bin/rqlited -http-addr 10.10.180.63:4001 -raft-addr 10.10.180.63:4002 -join http://10.10.180.61:4001 ~/node.3 > /tmp/node.3.log

Trying to view tables from rqlite:

    rqlite -H 10.10.180.62

    Welcome to the rqlite CLI. Enter ".help" for usage hints.

    10.10.180.62:4001> .tables

    ERR! Get "https://10.10.180.61:4001/db/query?q=SELECT+name+FROM+sqlite_master+WHERE+type%3D%22table%22": http: server gave HTTP response to HTTPS client

    10.10.180.62:4001> 

And a simple query (somehow use https now everywhere):

    curl -G 'http://10.10.180.62:4001/db/query?pretty&timings' --data-urlencode 'q=SELECT * FROM foo' -iv

*   Trying 10.10.180.62:4001...

* TCP_NODELAY set

* Connected to 10.10.180.62 (10.10.180.62) port 4001 (#0)

> GET /db/query?pretty&timings&q=SELECT%20%2A%20FROM%20foo HTTP/1.1

> Host: 10.10.180.62:4001

> User-Agent: curl/7.68.0

> Accept: */*

> 

* Mark bundle as not supporting multiuse

< HTTP/1.1 301 Moved Permanently

HTTP/1.1 301 Moved Permanently

< Content-Type: application/json; charset=utf-8

Content-Type: application/json; charset=utf-8

< Location: https://10.10.180.61:4001/db/query?pretty&timings&q=SELECT%20%2A%20FROM%20foo

Location: https://10.10.180.61:4001/db/query?pretty&timings&q=SELECT%20%2A%20FROM%20foo

< X-Rqlite-Version: v5.4.1

X-Rqlite-Version: v5.4.1

< Date: Fri, 25 Sep 2020 07:23:45 GMT

Date: Fri, 25 Sep 2020 07:23:45 GMT

< Content-Length: 0

Content-Length: 0

< 

* Connection #0 to host 10.10.180.62 left intact

[Philip O'Toole]

Hmmm, that is strange. I have a lot of automated testing of these cases as part of the build process, I'm surprised you're seeing something strange. Let me take a look.

To view this discussion on the web visit https://groups.google.com/d/msgid/rqlite/981fee40-97bf-49e0-9058-668bbb89f801n%40googlegroups.com.

[Philip O'Toole]

I found the bug and fixed it. I also increased test coverage so that this is caught should it happen again -- it wasn't being fully tested in previous releases.

5.4.2 is now available -- please let me know if this does, or does not, address the issue. I ran a quick sanity check by hand, with both HTTP and HTTPS, and it looks good to me.

Philip

[george....@gmail.com]

Now it's working, I've tested with http and htps connections. Thank you.

[Philip O'Toole]

Great, thanks for the update and the initial bug report.

To view this discussion on the web visit https://groups.google.com/d/msgid/rqlite/7e852d94-9ea0-462a-a5ed-033a76b23abbn%40googlegroups.com.