added support for certificates and insecure

[cooperspencer]

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

[dswarbrick]

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]

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]

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.

[boynux]

Thanks for this PR, I think this is a good addition. however I'm not sure if squid server supports client certs for this work, does it?

If you meant to support when the cache manager port is behind a secure port as the insecure flag implies then I think the right approach might be what's explained here: https://gist.github.com/denji/12b3a568f092ab951456?permalink_comment_id=1695690#gistcomment-1695690

Please let me know if I misunderstood anything :)