If you are behind a MITM proxy, it is not actually insecure to turn host verification off since the certificate you’d be verifying is fake anyway. If the proxy is not verifying the server’s identity for you by checking the actual certificate, that would be insecure but presumably the proxy is configured securely. Whether that is the case or not, the client has no control over that anyway, so there’s nothing we can do about it.
There are two things required for a client connection behind a MITM proxy to “just work”:
-
The client must have a CA root installed that allows it to verify fake certificates created by the MITM proxy. That seems to be the case here, since otherwise we’d get a different error.
-
The proxy should be configured to handle certificate revocation checks from Windows machines. That seems not to be the case here, as the error indicates that revocation checking failed.
The first requirement is necessary for all operating systems. As of Julia 1.6, we use system TLS engines on macOS and Windows, so if the MITM CA root has been added to the system certificate stores, then that step should be fine. On Linux, we look for a PEM file in common places and use the first one we find, so even though there’s no “system TLS engine” we ought to pick up a MITM CA root if one has been installed.
The second requirement only affects Windows because each OS does certificate revocation checking differently. Linux doesn’t do certificate revocation checks at all, which is obviously insecure, but also not our problem to solve. If there’s ever a standard way to handle certificate revocation checks on Linux, we can hook into it. MacOS does offline updates to its certificate revocation list, so this kind of error cannot happen: the system TLS engine checks a certificate against the revocation list that it already has; it doesn’t try to update that list during the host verification process. It may try (and fail) to update the CRL list at some other time, but that doesn’t block individual TLS requests.
Windows, on the other hand, does a synchronous certificate revocation checks while verifying each host’s identity. That means that if it hasn’t recently checked whether the certificate for a given host has been revoked, it will contact a Microsoft server to check that while it is in the process of verifying the validity of the certificate for the host you are trying to connect to. This is where people are hitting problems: they seem to have a MITM CA root installed, but when Windows tries to see if the certificate has been revoked, that check is being blocked or failing.
We could add an option to not do CRL checks while still doing certificate verification, but I’m not sure if this is actually necessary or useful. This problem only seems to occur when behind a MITM firewall, in which case it’s just as secure to skip verification altogether since the certificate you’d be verifying isn’t real anyway. You might as well turn host verification off altogether when you’re behind a MITM firewall.
It’s possible that I’m misunderstanding something here because this stuff is complicated and documentation is both poor and spread all across the Internet.