You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
One of the option in TLS vhost, sets the SNI extension with configured value, which is expected. But it does not validate the common-name present in the server certificate with the one that is configured. Hence handshake goes through fine, even if there is a mismatch in the common name and the vhost configured
To Reproduce
We need to have a client and server, In my case I am using fluent-bit in both client and server. Need to have client and server certificates to use them at client and server as we are going to use TLS
[INPUT]
Name syslog
#Tag local3_2.3.4.5
Listen 10.10.10.30
Port 38867
Parser syslog-rfc3164
Mode TCP
Buffer_Chunk_Size 64KB
tls on
tls.verify true
tls.ca_file /home/mhosur/ca.crt
tls.crt_file /home/mhosur/server.crt
tls.key_file /home/mhosur/server.key
[OUTPUT]
Name stdout
Match *
In both server and client, we need to upload the certificates, which can be found in attachments
About the certificates:
Both client & server certs are signed by a same CA
They both have a different common name
Expected behavior
The fluent-bit at client should have validated the common name present in the received server certificate during the handshake. And abort the connection if there is a mismatch.
[INPUT]
Name Tail
Tag local3_2.3.4.5
Path /var/log/test_logs
DB /tmp/local3_2.3.4.5
Buffer_Max_Size 64k
Buffer_Chunk_Size 64k
Mem_Buf_Limit 512
Refresh_Interval 30
[OUTPUT]
Name Syslog
Match local3_2.3.4.5
Host 10.10.10.30
Port 38867
Mode TCP
Syslog_Format rfc3164
Syslog_Message_Key log
net.connect_timeout 50
tls on
tls.verify true
tls.vhost validates.net
tls.ca_file /home/mhosur/ca.crt
tls.crt_file /home/mhosur/client1.crt
tls.key_file /home/mhosur/client1.key
[OUTPUT]
Name stdout
Match local3_2.3.4.5
At server:
[SERVICE]
parsers_file /usr/local/etc/fluent-bit/parsers.conf
storage.path /tmp/storage
log_file /var/log/fluent-bit.log
log_level debug
[INPUT]
Name syslog
#Tag local3_2.3.4.5
Listen 10.10.10.30
Port 38867
Parser syslog-rfc3164
Mode TCP
Buffer_Chunk_Size 64KB
tls on
tls.verify true
tls.ca_file /home/mhosur/ca.crt
tls.crt_file /home/mhosur/server.crt
tls.key_file /home/mhosur/server.key
[OUTPUT]
Name stdout
Match *
Environment name and version (e.g. Kubernetes? What version?):
Server type and version:
Operating System and version:ubuntu 22
Filters and plugins: SYSLOG, TAIL, TLS
Additional context
As vhost configured may server the purpose of getting the relevent certificate from the server, in case of mulitple servers running on the same IP, it does not accomplish its full use by not validating the common name in the received certificate.
However I found following two links related vhost working in older version 1.3.3. By the description present in them, it looks like it was validating common name before. Is this broken in later versions?
Links: fluent/fluent-bit-docs#507 #1796
The text was updated successfully, but these errors were encountered:
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.
muttanna2972
changed the title
Tls.vhost is not validating the common name of the server in server certificate
Tls.vhost is not validating the common name of the server in server certificate.
Jul 25, 2023
Bug Report
Describe the bug
One of the option in TLS vhost, sets the SNI extension with configured value, which is expected. But it does not validate the common-name present in the server certificate with the one that is configured. Hence handshake goes through fine, even if there is a mismatch in the common name and the vhost configured
To Reproduce
We need to have a client and server, In my case I am using fluent-bit in both client and server. Need to have client and server certificates to use them at client and server as we are going to use TLS
------FLB(client)--------------FLB(server)---------
At client:
[OUTPUT]
Name Syslog
Match local3_2.3.4.5
Host 10.10.10.30
Port 38867
Mode TCP
Syslog_Format rfc3164
Syslog_Message_Key log
net.connect_timeout 50
tls on
tls.verify true
tls.vhost validates.net
tls.ca_file /home/mhosur/ca.crt
tls.crt_file /home/mhosur/client1.crt
tls.key_file /home/mhosur/client1.key
[OUTPUT]
Name stdout
Match local3_2.3.4.5
At server:
[OUTPUT]
Name stdout
Match *
In both server and client, we need to upload the certificates, which can be found in attachments
About the certificates:
Expected behavior
The fluent-bit at client should have validated the common name present in the received server certificate during the handshake. And abort the connection if there is a mismatch.
Screenshots
Your Environment
parsers_file /usr/local/etc/fluent-bit/parsers.conf
storage.path /tmp/storage
log_file /var/log/fluent-bit.log
log_level debug
[INPUT]
Name Tail
Tag local3_2.3.4.5
Path /var/log/test_logs
DB /tmp/local3_2.3.4.5
Buffer_Max_Size 64k
Buffer_Chunk_Size 64k
Mem_Buf_Limit 512
Refresh_Interval 30
[OUTPUT]
Name Syslog
Match local3_2.3.4.5
Host 10.10.10.30
Port 38867
Mode TCP
Syslog_Format rfc3164
Syslog_Message_Key log
net.connect_timeout 50
tls on
tls.verify true
tls.vhost validates.net
tls.ca_file /home/mhosur/ca.crt
tls.crt_file /home/mhosur/client1.crt
tls.key_file /home/mhosur/client1.key
[OUTPUT]
Name stdout
Match local3_2.3.4.5
At server:
[SERVICE]
parsers_file /usr/local/etc/fluent-bit/parsers.conf
storage.path /tmp/storage
log_file /var/log/fluent-bit.log
log_level debug
[INPUT]
Name syslog
#Tag local3_2.3.4.5
Listen 10.10.10.30
Port 38867
Parser syslog-rfc3164
Mode TCP
Buffer_Chunk_Size 64KB
tls on
tls.verify true
tls.ca_file /home/mhosur/ca.crt
tls.crt_file /home/mhosur/server.crt
tls.key_file /home/mhosur/server.key
[OUTPUT]
Name stdout
Match *
Additional context
As vhost configured may server the purpose of getting the relevent certificate from the server, in case of mulitple servers running on the same IP, it does not accomplish its full use by not validating the common name in the received certificate.
However I found following two links related vhost working in older version 1.3.3. By the description present in them, it looks like it was validating common name before. Is this broken in later versions?
Links:
fluent/fluent-bit-docs#507
#1796
The text was updated successfully, but these errors were encountered: