search

boynux / squid-exporter

Squid Prometheus Exporter
https://www.boynux.com/squid-exporter
MIT License
134 stars 53 forks source link

added support for certificates and insecure #96

Open cooperspencer opened 4 months ago

cooperspencer commented 4 months ago

I added TLS support if squid runs on secure ports and also an option for insecure connections.

dswarbrick commented 4 months ago

As I understand it, this PR adds support for client TLS authentication when talking to the Squid manager endpoint, i.e. squid-exporter will communicate securely with Squid and identify itself with a client cert (if configured). Is that correct?

If so, then presumably you would need to configure an ACL on Squid to verify one or more attributes of the client's (i.e., squid-exporter) certificate that it presents in the TLS handshake. Can you perhaps elaborate on your use case?

cooperspencer commented 4 months ago

I guess this is a misunderstanding. This pull request is not about supporting client certificates, but supporting self signed certificates by adding a custom trust store. This way, the squid exporter can trust the certificate presented by squid without relying on the system trust database.

dswarbrick commented 4 months ago

Ok, but loading certificates into the Certificates slice of a tls.Config is for presenting to the other side of the connection, i.e.

    // Certificates contains one or more certificate chains to present to the
    // other side of the connection. ...
    Certificates []Certificate

When using the tls.Config for a client (i.e. with tls.Dial()), the Certificates are used to perform TLS client authentication.

Note that you don't have to use the host system's CA bundle.

    // RootCAs defines the set of root certificate authorities
    // that clients use when verifying server certificates.
    // If RootCAs is nil, TLS uses the host's root CA set.
    RootCAs *x509.CertPool

So if you wanted to support (and verify) a self-signed cert being used by Squid, you could simply add that cert to your tls.Config's RootCAs, and it would then be trusted. This avoids the need for squid-exporter to have the private key, and is also more fitting for a typical enterprise PKI scenario, i.e. using an in-house CA root certificate.

There is no reason for the client (i.e. squid-exporter) to present a TLS cert, unless you're trying to implement some kind of mutual TLS - in which case you would likely still want to refer to a custom root CA, used to sign the (distinct) certs on both sides of the connection.