git https clone must fail if end user used http.sslVerify=false

if git end user sets

> http.sslVerify=false

, for example command

git -c http.sslVerify=false clone https://<url>/x.git

then the public repo clone succeeds without any verification and turning off TLS verification does not provide any protection.

in this setup git users will access an git mirror (bitbucket mirror) server from external cloud, we wanted to ensure every git client present an valid cert before executing an git clone / pull operations.( intention is to have Audit trail of public repo close as well).

How do i block a git client user if user disables the TLS verification by setting http.sslVerify=false? ( to ensure a valid cert is presented by the git cli clients)

FYI, Bitbucket mirror hosted behind an Apache proxy where i can enable mTLS however seeking suggestion/advice here. How to ensure git client provides a valid ssl cert for all git operations every time so that we can log the SSL cert user in Apache logs or Application logs?

Thanks in advance.

Answering my own query as i found two solutions ( server side changes) to block Anonymous Access.

Method 1 : Enable mTLS at Apache proxy to enforce client to use a valid cert. Set the Apache directive "SSLVerifyClient require" and we will have cert user details printed in Apache logs ( custom logs to print ssl header values or using apache forensic logs)

Method 2: Enable feature.public.access=false in Bitbucket properties file which will enforce end users to send HTTPS token (both for public & private repos). in this case ssl client cert is not mandatory however CA root cert is required at minimum in the ssl client environment.

http.sslVerify is about validating the server certificate by the client, i.e. that the client properly authenticates the server in order to protect against man-in-the-middle attacks. This has nothing to do with "ensure every git client present an valid cert" - which would be use of client certificates so that the server can authenticate the client (mutual TLS).

There is no way for the server to ensure that the client is properly validating the server certificate. It can only be determined in the server that the client must have accepted the server certificate somehow since the TLS handshake succeeded. It cannot be observed why exactly the client has accepted the server certificate, i.e. if proper validation was done or not. It cannot even be observed that the connections comes from the intended client and not from some man-in-the-middle attacker instead.

The only way to figure out that the client is not checking server certificates is to make the client fail by presenting a wrong certificate. Of course a git clone will not succeed in this case, since either the client will not continue due to the wrong certificate or the server will not continue due to the client not properly checking the certificate. So this kind of check cannot be used to make git clone only possible with proper certificate validation.