cargo ssl download error behind proxy on windows - ssl

I cannot get cargo to commence any downloads under windows behind an authenticated proxy.
Here are my proxy settings:-
C:\Users\ukb99427\Downloads
λ set | grep http
https_proxy=http://user:pass#corporate.proxy:8080
http_proxy=http://user:pass#corporate.proxy:8080
Note the https_proxy has a http address. This allows something like git and incidentally rustup-init and rustup to work fine. Output from those are
λ rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: latest update on 2017-11-10, rust version 1.23.0-nightly (d6b06c63a 2017-11-09)
info: downloading component 'rustc'
33.4 MiB / 33.4 MiB (100 %) 2.7 MiB/s ETA: 0 s
But when running an equivalent cargo install command I get the following
λ cargo install libc
Updating registry `https://github.com/rust-lang/crates.io-index`
warning: spurious network error (2 tries remaining): [12/-2] [56] Failure when receiving data from the peer
warning: spurious network error (1 tries remaining): [12/-2] [56] Failure when receiving data from the peer
As a test I can run curl
λ curl --insecure https://github.com/rust-lang/crates.io-index -o registry.html
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 785k 0 785k 0 0 389k 0 --:--:-- 0:00:02 --:--:-- 393k
Alternatively I try setting the https_proxy to https://user:pass#corporate.proxy:8080
and get the following
λ cargo install libc
Updating registry `https://github.com/rust-lang/crates.io-index`
warning: spurious network error (2 tries remaining): [12/-2] [4] A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision. (Unsupported proxy 'https://user:pass#corporate.proxy:8080', libcurl is built without the HTTPS-proxy support.)
warning: spurious network error (1 tries remaining): [12/-2] [4] A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision. (Unsupported proxy 'https://user:pass#corporate.proxy:8080', libcurl is built without the HTTPS-proxy support.)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`
Caused by:
[12/-2] [4] A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision. (Unsupported proxy 'https://user:pass#corporate.proxy:8080', libcurl is built without the HTTPS-proxy support.)
For reference curl --version outputs
λ curl --version
curl 7.53.0 (x86_64-w64-mingw32) libcurl/7.53.0 OpenSSL/1.0.2k zlib/1.2.11 libssh2/1.8.0 nghttp2/1.19.0 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: IPv6 Largefile SSPI Kerberos SPNEGO NTLM **SSL** libz TLS-SRP HTTP2 HTTPS-proxy Metalink
Cargo version
λ cargo version
cargo 0.24.0-nightly (b83550edc 2017-11-04)
Is there any way to get cargo to use the same settings as rustup,git or curl? Other apps work ok, with sslverify=false (such as git), which is at best a work around, but would get me somewhere as opposed to nowhere.
This is all on Windows10, behind a authenticated proxy. With no user/pass given, it (and any application) exits with http error 407 which makes sense. For windows apps, they use the IE settings which work fine (for applications like Visual Studio Code or anything similar)
The only alternative I can think of is to force everything to use http only, but I don't know of any settings to make that happen for cargo.
Any thoughts on what else I can try?

I struggled with this a while but finally figured out a work around. I post this here as a possible solution for those behind corporate firewalls. It does, sadly, reduce adoption of rust if people can't install it easily at work.
Download the crates-io from github
git clone --bare https://github.com/rust-lang/crates.io-index.git
In $HOME/.cargo/config file set the registry like
[registry]
index = "file:///C:/Users/someuser/crates.io-index.git"
This stops the registry download via libgit-curl which apparently doesn't support https_proxy.
A longer term solution I think (but I've not tested this yet), is to rebuild cargo with libgit-curl supporting https.

Now (not sure if it was possible at the time) you have another possible solution for this issue, by updating your ~/.cargo/config this way :
[http]
proxy = "http://<user>:<password>#<proxy_url>"
check-revoke = false

Related

Jenkins “Publish over FTP plugin” returning “534 Policy requires SSL” for file upload

I am trying to configure "Publish over FTP plugin" for uploading files to FTP site (SSL enabled) from Jenkins (v2.7.4).
The check box "Use FTP over TLS" is enabled in the FTP host configuration (under Manage Jenkins > Configure system) and "Trusted Certificate" added.
"Test Configuration" is Successful, however file upload is failing with error : "534 Policy requires SSL"
Find below the verbose output from console :
[EnvInject] - Loading node environment variables.
Building in workspace /var/lib/jenkins/jenkins_home/workspace/TEST_FTP
[TEST_FTP] $ /bin/sh -xe /opt/tomcat/temp/hudson6047550741121880978.sh
+ touch test.txt
FTP: Connecting from host [localhost]
FTP: Connecting with configuration [site1] ...
220 Welcome to XXXXXXXXXXXXXX FTP Services
AUTH TLS
234 AUTH command ok. Expecting TLS Negotiation.
FTP: Logging in, command printing disabled
FTP: Logged in, command printing enabled
CWD /site1/upload
250 CWD command successful.
TYPE I
200 Type set to I.
CWD /site1/upload
250 CWD command successful.
PASV
227 Entering Passive Mode (XX,XX,XX,XX,XX,XX).
STOR test.txt
534 Policy requires SSL.
FTP: Disconnecting configuration [site1] ...
ERROR: Exception when publishing, exception message [Could not write file. Server message: [534 Policy requires SSL.
]]
Build step 'Send build artifacts over FTP' changed build result to UNSTABLE
[BFA] Scanning build for known causes...
[BFA] No failure causes found
[BFA] Done. 0s
Finished: UNSTABLE
Are there any additional configurations required for this plugin to work? Couldn't find any specific instruction in the wiki page : https://plugins.jenkins.io/publish-over-ftp
From RFC 2228, it could be that the security level is insufficient. Negociating TLS on the command port is probably not enough for this server and if it's required to also encrypt the data with a PROT P command (following a PBSZ command) then you are blocked with your problem.
The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or
APPE command if the current protection level is not at the level
dictated by the server's security requirements for the particular
file transfer.
You can activate the debugging then we can confirm everything is ok with the handshake and that it's a problem of insufficient security, by adding -Djavax.net.debug=all to your Jenkins startup.
It seems this Jenkins plugin doesn't support data channel encryption. Open a a feature request.

The system cannot infer the transport information from xxxx url

I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally

httperf: connection failed with unexpected error 0

Has anybody seen "httperf: connection failed with unexpected error 0" when running httperf with --ssl?
This is blocking my test on that domain. When I tested --ssl on https://google.com it worked fine.
On the other end of my "problematic" domain there is ELB, forwarding calls to heroku.
On my workstation: OSX 10.9.5 and httperf-0.9.0 (via brew)
I had the same issue, by looking at NGINX logs it turns out the SSL handshake fails because SSLv3 is disabled server side.
The project seemed a bit dead so I modified this file at line 924 :
I replaced SSLv3_client_method() with TLSv1_client_method()
Then the usual compilation stuff configure-make-install. Be sure to have openssl on your build machine.
Source : https://www.openssl.org/docs/ssl/SSL_CTX_new.html
The answer by #oto turned out be related to my fix as well. Basically, we stopped using SSLv3 on our server (and, apparently, all other ssl protocols used by httperf) due to the POODLE vulnerability, and httperf uses SSLv3, so it fails to connect.
Until they update httperf there seems to be no easy way around this. One way to fix it is to change from SSLv3 to TLSv1 by hand, as mentioned in the other answer.
I found this patch pull-request on GitHub. It changes the code so you can specify the ssl protocol with a flag, so I could force using TLSv1 instead of SSLv3.
For both fixes you will need to download the httperf source code, make the changes (like applying the patch), and then compile. I cloned the source from GitHub, so I had to run the autoreconf -i command before running make, but the instructions are pretty good. I had to use commit ed5c631 since the latest commits appear to be broken.

SSL version error when cloning with TortoiseHG https mode

I'm using TortoiseHG on win7 64b to clone repository using https protocol. I've installed and configured the public cert on my side so the validity of server cert can be checked.
However, i'm having the following error when trying to clone:
% hg clone --verbose -- https://***/hg/Trainings/train-repo1 "c:\sandboxes\hg"
SSL error: wrong version number
[command returned code 255 Wed Nov 06 14:28:47 2013]
I guess I have to configure the SSL version supported on Tortoise side somehow, but cannot find resources on internet about how to do. I'm looking for any explanation or documentation on the subject. Tks !
Note: the repo server force me to use https, and I have no control over it. (cannot switch to ssh)
I had a similar error message on an installation that had previously working without issue and no known changes to the server (which is under my control) or my local TortoiseHg install.
I tracked it down to having set the environment variables HTTP_PROXY and HTTPS_PROXY for an unrelated program on my computer.
I fixed it by adding the following to mercurial.ini:
[http_proxy]
host = <proxy-server>
no = <mercurial host ip address>
To fix this, I just updated TortoiseHG (via web or choco install tortoisehg), which in turn updated it's internal version of SSL, which I presume was so old bitbucket retired it.

Does buildout/easy_install/setup_tools verify SSL certificates?

I'm trying to diagnose this error:
Getting distribution for 'zc.buildout<2dev'.
Got zc.buildout 1.7.1.
Generated script '/opt/mytardis/releases/a549cd05272afe8f16c2fe5efe8158490acbde82/bin/buildout'.
Download error on http://pypi.python.org/simple/buildout-versions/: [Errno 104] Connection reset by peer -- Some packages may not be found!
Couldn't find index page for 'buildout-versions' (maybe misspelled?)
Download error on http://pypi.python.org/simple/: [Errno 104] Connection reset by peer -- Some packages may not be found!
Getting distribution for 'buildout-versions'.
STDERR: /usr/lib64/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'src_root'
warnings.warn(msg)
While:
Installing.
Loading extensions.
Getting distribution for 'buildout-versions'.
Error: Couldn't find a distribution for 'buildout-versions'.
It happens deep inside a Chef + buildout installation stack. One thing I have discovered is that if I attempt to access the buildout-versions package directly:
$ wget https://pypi.python.org/packages/source/b/buildout-versions/buildout-versions-1.7.tar.gz#md5=731ecc0c9029f45826fa9f31d44e311d
--2013-07-09 12:50:18-- https://pypi.python.org/packages/source/b/buildout-versions/buildout-versions-1.7.tar.gz
Resolving proxy.redacted.com... 123.45.67.8
Connecting to proxy.redacted.com|123.45.67.8|:8080... connected.
ERROR: certificate common name “*.a.ssl.fastly.net” doesn’t match requested host name “pypi.python.org”.
To connect to pypi.python.org insecurely, use ‘--no-check-certificate’.
I can access the file fine from my desktop. So I suspect the proxy (provided by a university, and this server has to use it to reach the web). It's set with https_proxy=....
Is this the likely cause of buildout failing? Any way around it?
Your version of wget is too old.
wget started to support SNI (Server Name Indication) only since version 1.14 and that TLS extension is needed to be presented the correct certificate on pypi.python.org.
Yes, zc.buildout and easy_install both use urllib2 to retrieve HTTPS resources, which does not verify SSL certificates:
Warning: HTTPS requests do not do any verification of the server’s certificate.
Your wget tool does verify certificates, but your local certificate authorities certificates are incomplete, it seems; see SSL certificate rejected trying to access GitHub over HTTPS behind firewall for instructions on how to update those.
As for your original error, it appears your firewall proxy is doing the peer resets.
As per PEP 476, Python 2.7.9 remedies this situation. From that version onwards, urllib2 will verify SSL certificates by default.
Since Python 2.7.9 (released) / 3.4.3 (released soon), certificates are validated by default:
HTTPS certificate validation using the system's certificate store is
now enabled by default. See PEP 476 for details.
https://www.python.org/downloads/release/python-279/
you can try it:
wget http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11-py2.7.egg#md5=fe1f997bc722265116870bc7919059ea --no-check-certificate