elazarl
"insecureSkipVerify: true" by default -- is this intentional?
In the certs.go file: https://github.com/elazarl/goproxy/blob/088f758167d2ea5cf2a8e14aab45f825ef47399e/certs.go#L26-L30 InsecureSkipVerify is set to true for both the "defaultTLSConfig" and the "tlsClientSkipVerify" structs.
The latter having this true makes sense given the name. But disabling TLS verification by default feels like a dangerous thing to be doing.
Is there a reason for this? I've searched through the Git history but cannot find a specific reason. The line dates back to the initial commit of this module 13 years ago.
It feels like it would be much safer to ensure verification is enabled by default, and make skipping verification opt-in. Unless I'm misunderstanding something, this makes the default mode of the proxy open to MITM attacks between the proxy server and the upstream host.
The Go source code documentation makes it explicitly clear setting this to true enables MITM attacks: https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/crypto/tls/common.go#L679-L685
// InsecureSkipVerify controls whether a client verifies the server's
// certificate chain and host name. If InsecureSkipVerify is true, crypto/tls
// accepts any certificate presented by the server and any host name in that
// certificate. In this mode, TLS is susceptible to machine-in-the-middle
// attacks unless custom verification is used. This should be used only for
// testing or in combination with VerifyConnection or VerifyPeerCertificate.
When you're using MITM, you usually don't have reliable root of trust, and working with self signed certificates anyway. It doesn't make sense that the client essentially ignores certificates, but the proxy would.
Proxies don't do certificate verification generally speaking.
I'm not sure I agree.
If you generate a private CA and add that to the trust store of the client, then you don't need to (and shouldn't be) skipping verification from the client to the proxy, since your proxy is now generating "trusted" leaf certificates.
That half of the connection (and whether it is verified or not) should also have no bearing whatsoever in influencing the proxy's verification of upstream certs. They're entirely separate connections, with independent security concerns.
It doesn't seem acceptable that my proxy would happily forward a request to attacker-server.com who maliciously intercepted the upstream when my client asked for github.com. This is inherently insecure by default.
Proxies don't do certificate verification generally speaking.
Would you be able to link me to documentation detailing this? It's not something I've ever seen in practice.
EDIT: Squid is very explicit about how dangerous it is to ignore certificate errors, in fact: https://wiki.squid-cache.org/Features/SslBump#other-settings
SECURITY WARNING: ignoring certificate errors is a security flaw. Doing it in a shared proxy is an extremely dangerous action. It should not be done lightly or for domains which you are not the authority owner (in which case please try fixing the certificate problem before doing this).