add support certificate subject verification for TLS sources

[jszigetvari]

Description of the problem

Currently TLS-enabled sources only conduct a limited number of checks on the certificates presented by connecting hosts that initiate TLS connections.
The validity of the certificate and the certificate chain is checked depending on the peer-verify() option, but it is not checked whether the certificate presented actually corresponds to the client or not.

Let us imagine a situation where:
Both clientA and clientB are hosts on the LAN and can send logs to the syslog server-ng over TLS. This means that they both have valid certificates issued by the same CA, that the syslog-ng trusts.
In a situation when clientB connects to the syslog-ng server using clientA's certificate (and private key), the syslog-ng server would allow clientB to connect, as it has a valid certificate, and the chain of trust also checks out. This can happen with peer-verify(required/trusted) too, as that setting doesn't imply checking whether the certificate actually belongs to the host presenting it.

In case of TLS-enabled destinations however (at least AFAIK), such checks are in place, so clients always verify whether the server is who it claims to be.

Proposed solution

Syslog-ng should add similar checks to sources as well, where it is checked whether the other communicating party is exactly who the certificate it presents was issued to.
This behavior however should be optional, and should be turned off by default to preserve configuration compatibility with older versions.
So in other words a new TLS option should be introduced that toggles this behavior.

[bazsi]

And what would you check? The ip address?

…

On Tue, Jun 2, 2020, 11:34 Janos SZIGETVARI ***@***.***> wrote: Description of the problem Currently TLS-enabled sources only conduct a limited number of checks on the certificates presented by connecting hosts that initiate TLS connections. The validity of the certificate and the certificate chain is checked depending on the *peer-verify()* option, but it is not checked whether the certificate presented actually corresponds to the client or not. Let us imagine a situation where: Both clientA and clientB are hosts on the LAN and can send logs to the syslog server-ng over TLS. This means that they both have valid certificates issued by the same CA, that the syslog-ng trusts. In a situation when clientB connects to the syslog-ng server using clientA's certificate (and private key), the syslog-ng server would allow clientB to connect, as it has a valid certificate, and the chain of trust also checks out. This can happen with *peer-verify(required/trusted)* too, as that setting doesn't imply checking whether the certificate actually belongs to the host presenting it. In case of TLS-enabled destinations however (at least AFAIK), such checks are in place, so clients always verify whether the server is who it claims to be. Proposed solution Syslog-ng should add similar checks to sources as well, where it is checked whether the other communicating party is exactly who the certificate it presents was issued to. This behavior however should be optional, and should be turned off by default to preserve configuration compatibility with older versions. So in other words a new TLS option should be introduced that toggles this behavior. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3312>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOK5QLGMDQJ4QIBSGEJD3RUTBUHANCNFSM4NQRYVAA> .

[jszigetvari]

Well, that depends on multiple things:

• whether the hostname contained in the certficate subject (if a hostname is listed within the subject) resolves to the IP address the connection is coming from
• whether the IP address contained in the certficate subject (if an IP address is listed within the subject) is the same as the IP address the connection is coming from
• and if not these, then we could probably check what is in the certificate extensions' DNS and IP fields, if they are filled in

[bazsi]

On Tue, Jun 2, 2020 at 1:34 PM Janos SZIGETVARI ***@***.***> wrote: Well, that depends on multiple things: - whether the hostname contained in the certficate subject (if a hostname is listed within the subject) resolves to the IP address the connection is coming from - whether the IP address contained in the certficate subject (if an IP address is listed within the subject) is the same as the IP address the connection is coming from

I for one wouldn't depend on reverse DNS for certificate validation. That's pretty easy to fool, you just need to become authoritive for a specific subnet's reverse domain, then you can claim to be anything. IP address could be useful, but again, in a lot of cases the IP address is more dynamic than the certificate (e.g. even servers receive their IP address via DHCP).

- and if not these, then we could probably check what is in the certificate extensions' DNS and IP fields, if they are filled in

The only validation I think would make sense is to selectively authorize acceptable $HOST values that we would accept from a specific certificate, a bit like SPF or DKIM for email. But I doubt anyone would actually use that feature.

…

-- Bazsi

[jszigetvari]

I didn't mention reverse DNS (as in getting the hostname based on the IP address). I was referring to getting the hostname from the certificate subject, and then trying to resolve it using DNS. Then if the result matches the IP address the connection came from, then things check out. (So in a sense my approach was doing it the other way around.)

I have seen at least one customer who put their hosts' IP addresses in their server certificate's subject. I know it's a very uncommon thing, nevertheless it is also a valid use-case. I am absolutely sure that users who would put (or include) the server's IP address into the certificate will have either static addressing in place, or will assign fixed IP addresses to their hosts by their DHCP setup.

On the other hand, if we could do the same kind of extra checks that we currently do on the destination side, I would be more than happy and content with it.

[faxm0dem]

This would probably make sense for MIPv6 https://tools.ietf.org/html/rfc6275