Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: Allow use of SSL client key/certificate for authenticating to DatabaseMirror #1194

Open
opoplawski opened this issue Mar 4, 2024 · 7 comments

Comments

@opoplawski
Copy link
Contributor

Describe the bug

We run local database mirrors that we protect by requiring SSL client certificates for authentication, but freshclam does not appear to have an option to use a client certificate when connecting to the database mirror.

@micahsnyder
Copy link
Contributor

Can you use the CURL_CA_BUNDLE environment variable?
https://docs.clamav.net/faq/faq-freshclam.html#problem-with-the-ssl-ca-cert

@opoplawski
Copy link
Contributor Author

That's not appropriate here - that is for having the client validate the certificate of the database mirror. I need the freshclam client to present a SSL certificate to the server that it will verify to allow access. The equivalent of the --cert and --key options to curl.

@micahsnyder
Copy link
Contributor

Ooohhh I see. Sorry I misunderstood.

@Kangie
Copy link
Contributor

Kangie commented Mar 21, 2024

Just out of curiousity, what drives your requirement to hide your clamav update mirror behind mTLS authentication? It's an update server - it doesn't really matter if excess clients are getting updates from you, outside of bandwidth usage.

If you're building out a commercial product based on clamav this sounds like a great PR. If it's driven by internal cyber-security concerns, well, your cyber-sec team is "holding it wrong".

@opoplawski
Copy link
Contributor Author

I feel like you are overly dismissive of our not wanting systems outside of our organization possibly using our server resources and network bandwidth. That feels like a valid concern to me.

@Kangie
Copy link
Contributor

Kangie commented Mar 21, 2024

Do you just have your internal update server exposed to the world? That's an unusual choice, but it's your org's choice to make.

I would consider options including exposing it only to internal networks, whitelisting IP blocks, VPN access for your staff, etc as alternatives.

If you'd like to see this support implemented quickly though, I'm sure that Micah would welcome a PR.

@opoplawski
Copy link
Contributor Author

We do have them public facing to serve our roaming users. Yeah, if this rises to a higher pain point and I ever have free time I'll try to do a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants