Cargo doesn't respect git's http.sslverify #1180
Comments
|
This will likely be done by binding the |
|
It seems a little bit complicated. We are behind the R&D proxy, the company classifies the connection zones, we are unfortunately in a zone we can git clone the outside code, no write access to outside. Cargo should get work by hacked locally, however, the process is that it firstly download a pre-built binary, that init binary couldn't work, so, all things blocked. I am not sure Cargo support cross-compile, if it does not we had to find a linux 64bit box without proxy access problem, build a hacked cargo, substitute the pre-built with that hacked, then get whole things work. BTW, there should be configuration item to tell cargo to ignore the SSL_certificate_check, rather than people to hack an ad-hoc version The problem is not solved, I will try it and update feedback here |
|
@yug any updates on this one? I am behind a http proxy and am unable to use cargo |
|
I hardcoded the hostnames on my windows box and it worked with tinyproxy/proxifier: c:\windows\system32\drivers\etc\hosts 174.129.244.175 www.crates.io crates.io s3-us-west-1-r-w.amazonaws.com |
|
@thebitllc hm that's interesting, if you don't have that hardcoding, does |
|
I managed to bypass this problem by setting up a crates.io proxy and a local index repo. See detailed description in chrisxue815/crates.io-proxy. |
|
Related issue on my side, actually my company has a HTTP/HTTPS proxy service which fakes SSL certificates for doing HTTPS session monitoring (i.e. decrypts https on the fly). To achieve this the proxy provider fakes https certificates by returning its own certificate to the client. Hence it would be great to have a cargo option similar to the --no-check-certificate flag of wget (or --insecure flag of curl, or as mentionned, sslVerify=false configuration of git) when downloading from crates.io. |
|
One question here is how Cargo may want to export this. It'd undeniably pretty questionable security practice to ignore certificate checks, but the use cases brought up here are indeed legitimate. We may want to do something beyond |
|
My case is the exact same as @guillon ... Behind a company wide proxy which fakes SSL certificates and am unable to use (and to ask others to use) cargo. Will give the crates.io-proxy thing a go but still, it would be so much better if this is resolved. |
|
@alexcrichton, I guess that if one provides a --insecure (or --no-check-certificate) flag, it would be natural for the user to expect that cargo will force the skip of certificate check for all transport connection initiated (git, curl or whatever application level client used by cargo to get artifacts from the network). If, independently of this flag, cargo uses a git client which honors the git configuration, no issue with this, i.e. the user may expect that if he sets a git configuration a git client may honor it. It is not cargo responsibility in this case. In summary, it would be good if cargo uses git/download libraries that honor "standard" git/download configurations. |
|
@the-shank @guillon Ditto, same case here, our company-wide proxy fakes SSL certificates, so we are basically forced to use I would, too, expect cargo to use whatever's listed in git configuration by default (if the user configured it in some specific way, that's the ground truth?), but maybe also provide a way to manually override this setting ( |
Git supports the `http.sslVerify` option as well as the `GIT_SSL_NO_VERIFY` environment variable for disabling validation of SSL certificates. This was removed from libgit2 in libgit2/libgit2@41698f22 citing bad security practice and how applications now had enough information to decide for themselves. There seems to be enough corporate environments (as mentioned in rust-lang#1180) where certificate validation won't work that this seems prudent for Cargo to support. Closes rust-lang#1180
|
I've pushed this up as #2408 |
|
Great. This issue was initially related to the git config only thus the proposed fix seems sufficient for this issue, should we create another issue for the file download case? For instance with the revision from pull request #2408, on a network with faked certificates: Caused by: Caused by: |
|
@guillon indeed! Out of curiosity, do you know if there's standard environment variable/config file configuration for curl to ignore certificates? I know there's a flag, but I'd hope to avoid a flag for now... |
|
@alexcrichton I do not now for env vars. Though, you have a ~/.curlrc file with the insecure option set as in: The curl command line will read it. |
|
Yea, the best you can do is probably see if |
|
Those who are running into this problem, one question that came up when @wycats and I were talking about this was why can't a local CA root be added? This is so blatantly a bad security practice it seems like the "standard way" of doing this would be for companies to install some trusted root CA which Cargo should then used to verify connections. |
|
Yes.
In the second case, indeed, one should install the root CA to solve the issue or the company IT should do it. |
|
It was also pointed out that we could also make it easier to use a custom store of certificates through standard mechanisms if modifying the "root store" is too hard: |
|
I'm new to rust, but I'm coming from the perspective of just trying to experiment / introduce it in our corporate environment. We have the same HTTPS proxy substituting certificates issue that's presented above. The strategy of adding the private CA into the right spots in the OS makes sense in general, but isn't always practical in a corporate environment. This is true for policy reasons, not just technical. In our case, we don't have root access to our machines and trying to convince teams of people to make certificate changes for a "language experiment" is definitely an uphill battle. In the end, lack of an alternative solution just increases the barrier to entry for trying rust out. From my point of view, either allowing me to force disable the certificate check or side load and point at our private CA certificate file would be workable solutions. |
|
I'm in exactly the same spot, was trying to introduce Rust to the team at work until we've hit this issue -- without root access (as is quite often the case) it's too much of a hassle to fix in a corporate environment and in some cases it's just plain implausible. This is pretty much the only reason we had to give up on Rust for now, at least until there's a solution that works (and doesn't require root rights). |
|
I am also in a corporate environment. |
|
@alexcrichton I understand that support for using cargo behind company wide proxy that fakes SSL Certificates isn't going to land into cargo as it is insecure practice. However, we (as in me) could fork cargo and modify that fork to support working behind company wide proxies. This would atleast enable folks like me (and @guillon, @aldanor, @aligature etc.) to work with rust and introduce it at our work places. The issue is that I am not very familiar with cargo. Could you give some pointers as to how to go about this. We can even name this fork "cargo-insecure" 😉 |
|
@alexcrichton What are the next steps for adding support for alternative cert stores as mentioned in #1180 (comment) ? |
|
@apaprocki Cargo should already respect platform-specific conventions like the environment variables |
|
Using a company-wide proxy is not necessarily insecure, provided that the proxy checks TLS certificates AND the proxy's certificate is on the client machines. In the relevant cases here, the proxy's certificate is known, so there should be a way to tell Cargo to use it. |
|
@DemiMarie yeah I think that's definitely the next step to take on this issue, ensuring that you can configure the certificates that Cargo uses and it then communicates that to all of its components. It's also be great to read this configuration from a standard location if it's already there as well. |
|
Very said that it is so complicated to use cargo behind our company wide proxy. I set up a localhost cntlm proxy for authentification. git works fine together with the cntlm, but still I need "sslVerify=false" in the git config. I guess rust will have a serious problem to get used in company environements. |
This adds a `http.cainfo` option to Cargo which reads CA information from a bundle to pass through to the underlying SSL implementation. This should allow configuration of Cargo in situations where the default certificate store doesn't contain the relevant certificates, such as behind corporate proxies. cc rust-lang#1180
|
Ok, I've opened a PR (#2917) for adding If you're on Linux you can also do that today by setting the |
Add `http.cainfo` config for custom certs This adds a `http.cainfo` option to Cargo which reads CA information from a bundle to pass through to the underlying SSL implementation. This should allow configuration of Cargo in situations where the default certificate store doesn't contain the relevant certificates, such as behind corporate proxies. cc #1180
|
Now that #2917 is merged, if anyone runs into this issue, you can try to add: [http]
cainfo = "path/to/cert.pem"to your |
|
@alexcrichton unfortunately Windows doesn't work with the new cainfo option. |
|
Ah yeah I've since learned that unfortunately Windows handles certificate On Sunday, August 14, 2016, yoava333 notifications@github.com wrote:
|
|
So, * At least if you are on a server with sufficiently old version of some enterprise Linux, in this case the proxy may be a red herring. |
|
With the "git the cli" config option (I forget what it is exactly) available as an alternative, do we still care to resolve this anyways? |
|
I think we'll still want to consider this yeah for all of Cargo's other interactions, as there's often https issues with crates.io as well |
|
If git is working, then open [net]
git-fetch-with-cli = true |
This used to be supported in libgit2, but it was removed. We should probably add back in explicit support somewhere.
cc #636, this has come up once or twice there.
The text was updated successfully, but these errors were encountered: