Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

syslog-ng tries TLS1.3 even with TLS1.2 cipher-suite(s) #3906

Closed
fencekicker opened this issue Feb 8, 2022 · 9 comments · Fixed by #3907
Closed

syslog-ng tries TLS1.3 even with TLS1.2 cipher-suite(s) #3906

fencekicker opened this issue Feb 8, 2022 · 9 comments · Fixed by #3907
Labels
bug

Comments

@fencekicker
Copy link

syslog-ng

Version of syslog-ng

syslog-ng 3 (3.30.1)
Config version: 3.29
Installer-Version: 3.30.1
Revision:
Compile-Date: Sep 11 2021 11:42:11
Module-Directory: /usr/lib/syslog-ng
Module-Path: /usr/lib/syslog-ng
Include-Path: /usr/share/syslog-ng/include
Available-Modules: disk-buffer,afprog,dbparser,hook-commands,afuser,affile,confgen,cryptofuncs,basicfuncs,csvparser,linux-kmsg-format,pseudofile,appmodel,system-source,afsocket,kvformat,timestamp,azure-auth-header,cef,secure-logging,syslogformat
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: off
Enable-TCP-Wrapper: off
Enable-Linux-Caps: off
Enable-Systemd: off

Platform

Container image based on Alpine 3.15.

Issue

We're using syslog-ng to forward log messages generated by some modules. Depending on configuration, the
messages can be sent over TLS. The modules are part of a bigger system which currently only knows TLSv1.2, and which wants to configure every syslog client to use certain TLSv1.2 only ciphers like AES128-GCM-SHA256, AES256-GCM-SHA384 etc. Thing is, even if I write the syslog-ng configuration to only use these TLSv1.2 ciphers, the ClientHello sent when syslog-ng initiates a connection includes extra ciphers which, as far as I can tell, are TLSv1.3 ciphers (and syslog-ng advertises TLSv1.3 support):

            Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
            Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
            Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)

Is this behavior intended?

I know it's strange to turn off the newer and supposedly safer version of the protocol, but I'm told this is for certification purposes - as far as I understand, it's not possible to use TLS1.3 for FIPS certification.

One example configuration snippet I use:

destination destination_0 {
network(
""
transport("tls")
port(6514)
tls( ca_dir("/etc/syslog-ng/tls/ca.d")
key_file("/etc/syslog-ng/tls/cert.d/client_key")
cert_file("/etc/syslog-ng/tls/cert.d/client_cert")
cipher-suite("ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256")
peer-verify(no)
)
);
};

We currently have syslog-ng 3.22, but verified this also happens in 3.30. I see in the latter version it's possible to specify 'ssl-options(no-tlsv13)', is that the only workaround? Or is there some other option to make the cipher-suite selection more strict?
@fencekicker fencekicker added the bug label Feb 8, 2022
@MrAnno
Copy link
Collaborator

MrAnno commented Feb 8, 2022

Thanks for opening this issue.

Cipher suites must be respected by syslog-ng, we'll look into that.

Until then, you can try adding ssl-options(no-tlsv13) to the tls() block, which should disable TLS 1.3 completely.

@MrAnno
Copy link
Collaborator

MrAnno commented Feb 8, 2022 •
edited

It seems OpenSSL provides a separate call for setting TLS 1.3 ciphers : SSL_CTX_set_ciphersuites().
SSL_CTX_set_cipher_list() (what we currently use) is only for TLS 1.2 and below.

I'll try to come up with a fix soon. Hopefully, we won't have to introduce a separate option for setting TLS 1.3 ciphers.

@bazsi
Copy link
Collaborator

bazsi commented Feb 8, 2022 via email

@fencekicker
Copy link
Author

Thanks for confirming the issue and the workaround.

It seems OpenSSL provides a separate call for setting TLS 1.3 ciphers : SSL_CTX_set_ciphersuites(). SSL_CTX_set_cipher_list() (what we currently use) is only for TLS 1.2 and below.

I ran syslog-ng 3.30 through ltrace in Alpine and, as far as I can tell, both APIs are called:

/ # grep "cipher.*ssl" lt_syslog-ng.txt 
37 07:25:15.287481 SSL_CTX_set_ciphersuites@libssl.so.1.1(0x7f812f4eead0, 0x7f812f96049c, 169, 0 <unfinished ...>
37 07:25:17.498967 SSL_CTX_set_cipher_list@libssl.so.1.1(0x7f812f4eead0, 0x55ac9fd64cb0, 1, 0 <unfinished ...>
[...]

I ran syslog-ng like this:

ltrace -tt -f -o lt_syslog-ng.txt -x "*@libssl.so*" -x "*@libcrypto.so*" /usr/sbin/syslog-ng -F -f /etc/syslog-ng/sy slog-ng.conf.old -ev

Could it be that openssl calls the TLSv1.3 API internally?

@MrAnno
Copy link
Collaborator

MrAnno commented Feb 9, 2022

Could it be that openssl calls the TLSv1.3 API internally?

Yes, as we currently don't set TLS 1.3 ciphers properly with SSL_CTX_set_ciphersuites(), those are probably internal calls or calls made by the dependencies of syslog-ng modules (libcurl, for example).

@MrAnno
Copy link
Collaborator

MrAnno commented Feb 9, 2022 •
edited

@bazsi I believe we can not "just fix" the cipher-suite() option without breaking things.

OpenSSL started using a separate call intentionally.
I could try to separate <=1.2 and 1.3 ciphers programmatically, or just supply the entire list for both the 1.2 and 1.3 setter methods (as unrecognized or mistyped ciphers are simply ignored in a documented manner by those calls), but this won't avoid breaking previous configurations, because:

If you explicitly configure your ciphersuites then care should be taken to ensure that you are not inadvertently excluding all TLSv1.3 compatible ciphersuites. If a client has TLSv1.3 enabled but no TLSv1.3 ciphersuites configured then it will immediately fail (even if the server does not support TLSv1.3) with an error message. Similarly if a server has TLSv1.3 enabled but no TLSv1.3 ciphersuites it will also immediately fail, even if the client does not support TLSv1.3.

This is why OpenSSL-based applications that let users configure their preferred cipher suite use separate options:

  • -cipher vs -ciphersuites (OpenSSL apps)
  • CipherString vs Ciphersuites (SSL_CONF_cmd-based apps)
  • SSLCipherSuite [protocol] cipher-spec (separate protocol specifier in Apache)
  • ssl_conf_command Ciphersuites vs ssl_ciphers (nginx)
  • tls-ciphersuites vs tls-cipher (OpenVPN)

If we really don't want to add a new option for 1.3 ciphers, we may require users to differentiate 1.3 ciphers, for example with a unique prefix (similarly to the Apache protocol specifier). To be fully compatible with older syslog-ng versions and configurations, we should not restrict the default 1.3 cipher suite in case no TLS1.3 cipher was listed in cipher-suite() by the user. This would be really confusing in my opinion, so I'd go with a separate option, for example: tls13-cipher-suite().

@MrAnno
Copy link
Collaborator

MrAnno commented Feb 9, 2022 •
edited

The following would work as well (IMHO it looks better than separate options):

Compat method (only for TLS 1.2-and-older):

tls(
  cipher-suite("list:of:old:ciphers")
)

Preferred new method:

tls(
  cipher-suite(tls12("list:of:old:ciphers"), tls13("list:of:new:ciphers"))
)

@bazsi
Copy link
Collaborator

bazsi commented Feb 9, 2022 via email

@MrAnno MrAnno mentioned this issue Feb 9, 2022
Merged
@MrAnno
Copy link
Collaborator

MrAnno commented Feb 9, 2022 •
edited

#3907 will make it possible to restrict TLS 1.3 ciphers.

Specifying an empty TLSv1.3 list is not allowed by OpenSSL, so ssl-options(no-tlsv13) can be considered as the official and the only way of disabling TLS 1.3 completely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

tls: add version-specific cipher suite options MrAnno/syslog-ng
3 participants
@bazsi @MrAnno @fencekicker