[syslog-ng] TLS "trusted-dn" Question

Attila Szakács attila.szakacs at axoflow.com
Mon Apr 3 12:36:08 UTC 2023


Thanks! I will try to implement it this week, or if I won't have the time
for it, I will create a feature request for it.

In the meantime, I would like to ask: will there be any way you can try out
the new feature before a stable release? I can provide you deb or rpm
packages or a container image manually, or when we merge it to master, it
will be available in our nightly APT repo and nightly docker image. I can
provide you a patch, if you are building locally, but I am afraid that the
change won't trivially apply to 3.31, as there have been modifications
around TLS since then. Does any of this work for you?

Cheers,
Attila

On Thu, Mar 30, 2023 at 5:32 PM David Hauck <davidh at netacquire.com> wrote:

> Hi Attila,
>
>
>
> *The trusted-dn() option is used for an additional verification step to
> reject clients/servers*
>
>
>
> Ah, OK, yes, I think I misread (or misinterpreted) this. I get how this is
> used now, thx.
>
>
>
> *Could you kindly confirm that this is what you are looking for?*
>
>
>
> Yes, exactly. This is similar to what (for e.g.) the
> SSLCACertificate{File|Path} mod_ssl directives are used for with the Apache
> HTTP Server and its HTTPS operation (see
> https://httpd.apache.org/docs/2.4/mod/mod_ssl.html). Without this
> connecting clients aren’t given any hints that can help them provide a
> proper client certificate (when they otherwise have many to choose from,
> each possibly signed by different CAs).
>
>
>
> Thanks,
>
> -David
>
>
>
> *From:* syslog-ng <syslog-ng-bounces at lists.balabit.hu> *On Behalf Of *Attila
> Szakács
> *Sent:* Thursday, March 30, 2023 3:12 AM
> *To:* Syslog-ng users' and developers' mailing list <
> syslog-ng at lists.balabit.hu>
> *Subject:* Re: [syslog-ng] TLS "trusted-dn" Question
>
>
>
> Hi David,
>
>
>
> The trusted-dn() option is used for an additional verification step to
> reject clients/servers, which provide a cert having such a *subject*
> field that does not match with any of the patterns set in trusted-dn().
>
>
>
> Unfortunately, I think that the first sentence in the documentation is a
> bit misleading:
>
> *Description: To accept connections only from hosts using certain
> certificates signed by the trusted CAs, list the distinguished names of the
> accepted certificates in this parameter. For example, using trusted-dn("*,
> O=Example Inc, ST=Some-State, C=*") will accept only certificates issued
> for the Example Inc organization in Some-State state.*
>
>
>
> If I understand correctly, what you would like to achieve is defined in
> https://www.ietf.org/rfc/rfc5246.txt
> <https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc5246.txt&data=05%7C01%7Cdavidh%40netacquire.com%7C4d2481e9962047dc420d08db31073b8e%7Cec65e18eede24cedbdab49355e3f602d%7C0%7C0%7C638157679363439549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wL9mYnHT0wDAWeUPj1DCRdF1DcwQUpguUech2vhKb7s%3D&reserved=0>
> -> 7.4.4. Certificate Request:
>
>    certificate_authorities
>
>       A list of the distinguished names [X501] of acceptable
>
>       certificate_authorities, represented in DER-encoded format.  These
>
>       distinguished names may specify a desired distinguished name for a
>
>       root CA or for a subordinate CA; thus, this message can be used to
>
>       describe known roots as well as a desired authorization space.  If
>
>       the certificate_authorities list is empty, then the client MAY
>
>       send any certificate of the appropriate ClientCertificateType,
>
>       unless there is some external arrangement to the contrary.
>
>
>
> This is not implemented in syslog-ng, yet, but it could be done easily with SSL_set_client_CA_list() <https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FSSL_get0_CA_list.html&data=05%7C01%7Cdavidh%40netacquire.com%7C4d2481e9962047dc420d08db31073b8e%7Cec65e18eede24cedbdab49355e3f602d%7C0%7C0%7C638157679363439549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v1Hbhcgm4Bf2zw0AYF6%2F177xXLXxjkU5HhwLPCBfDS0%3D&reserved=0>:
>
> *SSL_set_client_CA_list() sets the list of CAs sent to the client when requesting a client certificate for the chosen ssl, overriding the setting valid for ssl's SSL_CTX object.*
>
> Could you kindly confirm that this is what you are looking for?
>
>
>
> Cheers,
>
> Attila
>
>
>
> On Wed, Mar 29, 2023 at 8:42 PM David Hauck <davidh at netacquire.com> wrote:
>
> Hi,
>
> I'm currently using syslog-ng OSE v3.31.2 and trying to get a TLS
> configured endpoint to use the 'trusted-dn()' TLS option. I'm having
> trouble getting syslog-ng to return these DN specifiers in the Certificate
> Request option during the TLS negotiation so that clients can properly
> condition their supplied client certificates.
>
> I invariably see the following TLS negotiations (empty DNs list) in my
> Wireshark captures (as returned by the syslog-ng server):
>
> TLSv1.2 Record Layer: Handshake Protocol: Certificate Request
>     Content Type: Handshake (22)
>     Version: TLS 1.2 (0x0303)
>     Length: 58
>     Handshake Protocol: Certificate Request
>         Handshake Type: Certificate Request (13)
>         Length: 54
>         Certificate types count: 3
>         Certificate types (3 types)
>         Signature Hash Algorithms Length: 46
>         Signature Hash Algorithms (23 algorithms)
>         Distinguished Names Length: 0                          <-----
> always '0'
>
> In these cases my clients choose random client certificates that can't be
> refined to certificates signed by those expected (via the 'trusted-dn()'
> values) by the server and the connection is immediately closed.
>
> Here's the syslog-ng.conf entry for these sources:
>
> source s_515_tls {
>    network( transport(tls) port(515) ip-protocol(6)
>       tls(ca-dir("/etc/ssl/certs") key-file("/root/naservers.key")
> cert-file("/root/naservers.cer")
>          peer-verify(required-trusted) trusted-dn("CN=*.netacquire.com
> <https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fnetacquire.com%2F&data=05%7C01%7Cdavidh%40netacquire.com%7C4d2481e9962047dc420d08db31073b8e%7Cec65e18eede24cedbdab49355e3f602d%7C0%7C0%7C638157679363439549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X5NIUWuYD5F4GQ6WbnW%2F5HMrjJFkeg%2Fh4ma9xUMdN8w%3D&reserved=0>"))
> );
> };
>
> I've tried several variants of the 'trusted-dn()' values, including other
> wildcards for country, state, etc. I always see a DNs list of zero size in
> the TLS Certificate Request option returned by the server. As expected
> switching to 'peer-verify(required-untrusted)' results in successful
> negotiation (with expected server-side errors indicating problems
> associated with the client certificates) and subsequent successful
> client/server logging.
>
> I figure I must be missing something obvious ;). Any ideas?
>
> Here's my syslog-ng version info:
>
> [logdest:~]# syslog-ng --version
> syslog-ng 3 (3.31.2)
> Config version: 3.29
> Installer-Version: 3.31.2
> Revision:
> Compile-Date: Nov  9 2021 12:52:59
> Module-Directory: /usr/lib/syslog-ng
> Module-Path: /usr/lib/syslog-ng
> Include-Path: /usr/share/syslog-ng/include
> Available-Modules:
> tfgetent,mod-python,cryptofuncs,hook-commands,kvformat,cef,afuser,linux-kmsg-format,map-value-pairs,system-source,azure-auth-header,csvparser,affile,afprog,secure-logging,http,examples,timestamp,afsocket,confgen,stardate,dbparser,xml,disk-buffer,appmodel,afsnmp,add-contextual-data,afstomp,graphite,json-plugin,basicfuncs,syslogformat,pseudofile,tags-parser
> Enable-Debug: off
> Enable-GProf: off
> Enable-Memtrace: off
> Enable-IPv6: on
> Enable-Spoof-Source: off
> Enable-TCP-Wrapper: on
> Enable-Linux-Caps: on
> Enable-Systemd: off
>
> Thanks,
> -David
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> <https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Flists.balabit.hu%2Fmailman%2Flistinfo%2Fsyslog-ng&data=05%7C01%7Cdavidh%40netacquire.com%7C4d2481e9962047dc420d08db31073b8e%7Cec65e18eede24cedbdab49355e3f602d%7C0%7C0%7C638157679363439549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=E48rxdUkpoLsBgppz2Sm1%2F%2BikzdO8Q%2BxCt0KaghFig4%3D&reserved=0>
> Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng
> <https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.balabit.com%2Fsupport%2Fdocumentation%2F%3Fproduct%3Dsyslog-ng&data=05%7C01%7Cdavidh%40netacquire.com%7C4d2481e9962047dc420d08db31073b8e%7Cec65e18eede24cedbdab49355e3f602d%7C0%7C0%7C638157679363439549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=l2AI1TflzfBzXX6Yym2FfkuK8BfCrj4PCTAXTcF0hYg%3D&reserved=0>
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
> <https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.balabit.com%2Fwiki%2Fsyslog-ng-faq&data=05%7C01%7Cdavidh%40netacquire.com%7C4d2481e9962047dc420d08db31073b8e%7Cec65e18eede24cedbdab49355e3f602d%7C0%7C0%7C638157679363439549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ccq%2F%2BRAuUwczH5Z4v%2FA9whYHcuXu2A5Bz39D64%2Bc5Hw%3D&reserved=0>
>
> *External Email Warning!* Use caution before clicking links or opening
> attachments.
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20230403/901ccbb3/attachment-0001.htm>


More information about the syslog-ng mailing list