TLS security issue: tls.verify is not validating host subject alternative name

[JSchy65]

Bug Report

If tls.verify is set to on on the client side, the servers's subject alternative name (SAN) will still not be validated.

fluent-Bit Version 2.1.10 Ubuntu 22.04.2 LTS

Reproduction

The client establishs a connection with the host other.fluent-backoffice.de but get a certificate presented by the host with the SAN my.fluent-backoffice.de. It is obvious, that this names not match.

You find all necessary certificates and keys for reproduction in the zip file attached to this issue.

Excerpt from server's certificate data:

X509v3 Subject Alternative Name:
    DNS:my.fluent-backoffice.de

Fluent Bit configuration on client site:

[SERVICE]
    flush 1
    log_level debug

[INPUT]
    name  dummy
    dummy {"message": "custom dummy message"}

[OUTPUT]
    name   forward
    match  *
    host          other.fluent-backoffice.de
    port          24224
    tls           on
    tls.verify    on
    tls.debug     4
    tls.ca_file   /etc/fluent-bit/fluent-root.crt
    tls.crt_file  /etc/fluent-bit/fluent-client.crt
    tls.key_file  /etc/fluent-bit/fluent-client.key

/etc/hosts on client site:

92.168.55.11   other.fluent-backoffice.de

Fluent Bit configuration on server site:

[SERVICE]
    flush 1
    log_level debug

[INPUT]
    name   forward
    listen 0.0.0.0
    port   24224
    tls             on
    tls.verify      on
    tls.debug       4
    tls.ca_file     /etc/fluent-bit/fluent-root.crt
    tls.crt_file    /etc/fluent-bit/fluent-backoffice.crt
    tls.key_file    /etc/fluent-bit/fluent-backoffice.key

[OUTPUT]
    name stdout
    match *

Expected behaviour

If, like in that case, the host presents a certificat not matching the name of the host called by the client, the host name validation must fail and the TLS connection must not be established. Because of tls.debug is set to 4, in the client's site Fluent Bit log, there should be [debug] and/or [error] messages saying something like "host name validation failed".

Actual behaviour

The connection is established without any error. No error or debug message occurs in the client's or host's log. tls.debug 4 does not generate any tls [debug] message at all I think.

Countercheck

Checked with curl, if the expected behavour will occur:

curl https://other.fluent-backoffice.de:24224 --cacert /etc/fluent-bit/fluent-root.crt --cert /etc/fluent-bit/fluent-client.crt --key /etc/fluent-bit/fluent-client.key -v

You will get that messages:

* Server certificate:
*  subject: CN=fluent-backoffice
*  start date: Oct 19 15:47:01 2023 GMT
*  expire date: Dec  5 15:47:01 2033 GMT
*  subjectAltName does not match other.fluent-backoffice.de
* SSL: no alternative certificate subject name matches target host name 'other.fluent-backoffice.de'
* Closing connection 0

That means, that curl validates the host's certificate as expected. It detects, that the name in the hosts's certificate doesn't match the host called by the client. With curl, all is fine.

Now change the /etc/hosts to verify what happens, if the name in the host's certificate matches the name of the host called:

92.168.55.11   my.fluent-backoffice.de

Also in the client.config, change the host to:

host my.fluent-backoffice.de

After restarting Fluent-Bit, it works as expected. The tls connection is established and messages are successfully send from the client to the server.

curl also works as expected:

curl https://my.fluent-backoffice.de:24224 --cacert /etc/fluent-bit/fluent-root.crt --cert /etc/fluent-bit/fluent-client.crt --key /etc/fluent-bit/fluent-client.key -v

Now you will get the messages:

* Server certificate:
*  subject: CN=fluent-backoffice
*  start date: Oct 19 15:47:01 2023 GMT
*  expire date: Dec  5 15:47:01 2033 GMT
*  subjectAltName: host "my.fluent-backoffice.de" matched cert's "my.fluent-backoffice.de"
*  issuer: CN=fluent-root
*  SSL certificate verify ok

Unqualified guess about the cause

flb_ouput.c line 871:

else if (prop_key_check("tls.verify", k, len) == 0 && tmp) {
        ins->tls_verify = flb_utils_bool(tmp);
        flb_sds_destroy(tmp);
    }
    else if (prop_key_check("tls.debug", k, len) == 0 && tmp) {
        ins->tls_debug = atoi(tmp);
        flb_sds_destroy(tmp);
    }

tls.verify and tls.debug are the only two parameters in that code block, where a check against tmp is done. Is something wrong here ??

Please add the correct hostname validation to Fluent Bit.

necessary-certs.zip

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the exempt-stale label.

[JSchy65]

Because there was no reaction on this issue since Oct. 20. and because in my oppinion it is critical, I placed it as a security vulnerability now:

https://github.com/fluent/fluent-bit/security/advisories/GHSA-rvxv-vp29-qf2h

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the exempt-stale label.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[edsiper]

re-opening and assigning to @cosmo0920 for triagging