HBA: Enforcing transport ssl breaks other authentication methods

CrateDB version

4.6.4

CrateDB setup information

Number of nodes: 1 (just for trying out)

 auth.host_based.enabled: true
 auth:
   host_based:
     config:
       0:
         user: crate
         address: _local_
         method: trust
       1: 
         user: crate
         address: 10.10.10.10
         method: trust
         protocol: http
         ssl: on
       2:
         protocol: transport
         method: cert
         ssl: on
       3:
         protocol: http
         ssl: on
         method: password

<- snip ->
 # Enable encrypted communication for the HTTP endpoints:
 ssl.http.enabled: true
 
 # Enable encrypted communication for the PostgreSQL wire protocol:
 ssl.psql.enabled: true
 
 # Encrypted communication within the cluster
 ssl.transport.mode: on
<- snip ->

Steps to Reproduce

1. Spin up a fresh crate installation
2. Configure a ssl keystore
3. Configure HBA and SSL as in the snipping above.
4. Try to connect from 10.10.10.10 with curl

Expected Result

My expected result is:

• Localhost can connect on any protocol as the super user
• 10.10.10.10 can connect using https as the super user
• Other nodes can connect using transport/ssl with certificate auth
• Everything else requires https and a password

Actual Result

To me it seems that crate thinks that the clients need to be authenticated via certificates. This happens from localhost, 10.10.10.10 and from clients that do not have a matching host in the config.

$ curl -4 https://testhost1:4200/ --insecure
curl: (56) OpenSSL SSL_read: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate, errno 0

If I remove the transport entry

       2:
         protocol: transport
         method: cert
         ssl: on

It seems to be work correctly. Localhost and 10.10.10.10 work directly, from somewhere else I need a password.

[fetzerms]

I am currently on vacation and back next week. I’ll send an update as soon as I can.

[BaurzhanSakhariev]

Fixed, will be available in the next hot fix release.

In a meantime possible workaround - when I started a node with the same config on my machine and did a curl from the same machine it worked - because I added self signed cert into the store and crate node could recognise it since it used the same store.

Crate node (server) has client auth which can be no, optional and required - and you faced optional because of the bug. Normally its a big deal since certificate can be not provided at all(because it’s optional) but if it’s provided it should be valid/trusted and curl reacted to TLSv1.3 (IN), TLS handshake, Request CERT (13): by providing a cert which was rejected by the node.

--insecure option is about ignoring incoming server’s cert validation but not the opposite so it didn’t help

https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art042