add support certificate subject verification for TLS sources #3312
Comments
|
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>
.
|
|
Well, that depends on multiple things:
|
|
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
|
|
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. |
|
This would probably make sense for MIPv6 https://tools.ietf.org/html/rfc6275 |
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.
The text was updated successfully, but these errors were encountered: