Allow CURLOPT_SSL_VERIFYPEER option enable/disable in libfreshclam_internal.c

[shakaran]

In libfreshclam_internal.c there are a function called create_curl_handle() where all the curl options are set.

My proposal is add some struct variable to handle the parameter enableVerifyOption and the curl setopt like this:

if (CURLE_OK != curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, enableVerifyOption)) {
            logg("!create_curl_handle: Failed to set CURLOPT_SSL_VERIFYPEER!\n");
        }

Because I try to set global config for curl, creating in ~/.curlrc a file with "insecure" to skip the warning with certificate.

In curl command line, you have the option -k or --insecure for enable this flag. But since this is called via the C API, the current clamav users don't have a way to enable/disable this flag in command line or config file in freshclam.conf.

Why would be useful this? Because when you have DMZ zones machines, that access via .gov proxies, the .gov could not want add the Cloudflare certificate to the proxy or you cannot have access as BOFH to that machine.

This only could be solved if the proxy gives you a .cer or .crt file of issuer, which could be or not possible to run as:

Count the name of certs: $ grep -c "BEGIN CERTIFICATE" /etc/pki/tls/certs/ca-bundle.crt

Add the cert:

sudo cp yourproxycertificateprovided.crt yourproxycertificateprovided.pem /etc/pki/ca-trust/source/anchors
sudo update-ca-trust
sudo update-ca-trust enable
sudo update-ca-trust extract

Count the name of certs (checking that you have one more): $ grep -c "BEGIN CERTIFICATE" /etc/pki/tls/certs/ca-bundle.crt

Check that it is present in ca-bundle:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt | openssl pkcs7 -print_certs | grep subject | grep -i yourname

An example of failure update of daily.cvd diff file, when you cannot add the cert in the proxy :

downloadFile: Download destination: /var/lib/clamav/tmp.2a43c6947d/clamav-9ccd8390fd78570c1ee8fe2b14d9ebae.tmp
* About to connect() to proxy someimportantdomain.gov port 8080 (#11)
* Trying 123.123.123.123...
* Connected to someimportantdomain.gov (123.123.123.123) port 8080 (#11)
* Establish HTTP proxy tunnel to database.clamav.net:443

CONNECT database.clamav.net:443 HTTP/1.1
Host: database.clamav.net:443
User-Agent: ClamAV/0.103.5 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64, UUID: bla-bla)
Proxy-Connection: Keep-Alive
Connection: close

< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Server certificate: 
* subject: CN=sni.cloudflaressl.com,O="Cloudflare, Inc.",L=San Francisco,ST=California,C=US
* start date: Jul 15 00:00:00 2021 GMT
* expire date: May 20 04:04:42 2022 GMT
* common name: sni.cloudflaressl.com
* issuer: E=someuser@someimportantdomain.gov,CN=ssl.services.someimportantdomain.gov,O=someimportantdomain,L=Default City,ST=SOMESTATE,C=SOMECOUNTRY
* NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)
* Peer's certificate issuer has been marked as not trusted by the user.
* Closing connection 11
ERROR: Download failed (60) ERROR: Message: Peer certificate cannot be authenticated with given CA certificates
ERROR: Can't download daily.cvd from https://database.clamav.net/daily.cvd
Giving up on https://database.clamav.net...
ERROR: Update failed for database: daily
ERROR: Database update process failed: Connection failed
ERROR: Update failed.

The idea is have a flag in freshclam command that allow disable the Peer verification, for example:

freshclam -k

or

freshclam --insecure

or

freshclam --noverifycert

This would allow update with proxy without break with errors like:

NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)

or

Peer certificate cannot be authenticted with given CA certificates

[micahsnyder]

Not a bad idea. Right now you can also change the freshclam.conf option DatabaseMirror from:

DatabaseMirror database.clamav.net

to

DatabaseMirror http://database.clamav.net

so it will do the old-style HTTP download.
ClamAV verifies the downloaded CVD database archives are signed by our private signing key so switching from HTTPS to HTTP shouldn't bother you much.

[roncrivera]

The above suggestion worked for me. Thanks @micahsnyder for the tip!