wget fails to download through a proxy server with the following message: Invalid request -- HOST header was not sentUnable to establish SSL connection.
Example:
[root#foosrv0234ccpra ~]# wget https://packages.chef.io/stable/el/6/chefdk-0.18.26-1.el6.x86_64.rpm
--2016-09-27 16:57:44-- https://packages.chef.io/stable/el/6/chefdk-0.18.26-1.el6.x86_64.rpm
Resolving deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com (deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com)... 129.35.62.40
Connecting to deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com (deehprx024ccpxa.ehn.sr.dev.sdc.mycomp.com)|129.35.62.40|:8080... connected.
Proxy tunneling failed: Invalid request -- HOST header was not sentUnable to establish SSL connection.
[root#foosrv0234ccpra ~]# env|grep proxy
http_proxy=http://barsrvprx024ccpxa.ehn.sr.dev.sdc.mycomp.com:8080
https_proxy=http://barsrvprx024ccpxa.ehn.sr.dev.sdc.mycomp.com:8080
no_proxy=barsrvacp014ccpra,barsrvchf014ccpra.ssm.sdc.gts.mycomp.com,localhost,127.0.0.1,barsrvacp014ccpra.ssm.sdc.gts.mycomp.com
It took me a while to get through this, so I'm sharing the issue on StackOverflow. Please have a look at the answer below.
The problem above happens because HTTP 1.1 requires the client to provide a HOST header and the proxy server does not support HTTP 1.1 (refer to RFC 2616 for more details on this requirement).
Some alternatives:
Upgrade your proxy to support HTTP 1.1
Downgrade wget to a version that only supports HTTP 1.0 (wget v1.12 or below)
Find another way to force all HTTP calls to be made using 1.0 and not 1.1 (I haven't explore this possibility and I'm not sure how to do it... downgrading wget solved my issue)
Related
I am new to HTTPs. In our application to integrate with another system we were given HTTPs URLs along with their certificates. Our team added those certificates in the test store. Now when we are sending request on those URLs, we are getting “Unsupported or unrecognized SSL message”.
And if I do curl -v on that URL, I get error:1408F10B:SSL routines:ssl3_get_record:wrong version number.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
Both of these errors are due to the same reason?
It is very likely that the server does not speak TLS at all.
The client will start with the TLS handshake and the server will reply to this with some non-TLS response. The client expect the server to do its part of the TLS handshake though. Thus it will try to interpret the servers as response as TLS. This will lead to strange error messages depending on the TLS stack used by the client.
With OpenSSL based stacks it will often result in wrong version number, since the trying to extract the TLS version number for the expected TLS record and get some unexpected results since the server did not actually send a TLS record.
Is it problem on our side or this need to be fixed by other systems who shared those URLs with us.
If this is exact the URL you are supposed to use (i.e. no simply changing of http:// to https:// on your site) then it is likely a server side problem. But it might also be a problem of some middlebox or software in the network path to the server, like some antivirus, firewall or captive portal hijacking your data and denying access to the remote system with an error message.
In my case, I had on apache2 another badly configured virtual host. On the other wrong virtual host there was a http virtual server on port 443!!!
The second virtual host was correct but apache cannot use different protocols on the same port for different virtual hosts.
After removing the http on port 443 configuration all other https hosts worked and error
error:1408F10B:SSL routines:ssl3_get_record:wrong version number"
disapeared
I've been playing around with Curl, trying to do what should be a simple POST of a file to a web service for a couple of days and not getting anywhere.
The target POST service is unauthenticated HTTPS. When trying to run my POST request via Curl or via Informatica, I am getting an SSL handshake failure with both methods.
For example:
curl -X POST -F 'file=#filename.dat' https://url
I have been able to get this to work using Postman, so I know the service works. According to network security, SSL is disabled in this environment. Am I out of luck, or is there a way to get this to work without SSL?
Specific error encountered:
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
By default, a client establishing a HTTPS URL connection will check the validity of a SSL certificate - otherwise, what's the point of using SSL?
In your case, you are saying "Pretend to use HTTPS but actually, ignore the certificate", because it's invalid, or you are still getting one, or you are in the development phase (I hope the latter is true, and get or create a valid sever certificate when needed).
But curl doesn't know that. It is assuming you are asking it to establish a connection with an HTTPS endpoint - thus it will try to validate the certificate - which, in your case, may be the source of the failure.
Try curl -k -X POST -F 'file=#filename.dat' https://url
From the manpage:
-k, --insecure
(TLS) By default, every SSL connection curl makes is verified to be secure. This option allows curl to proceed and operate even for server connections otherwise considered insecure.
The server connection is verified by making sure the server's certificate contains the right name and verifies successfully using the cert store.
See this online resource for further details:
https://curl.haxx.se/docs/sslcerts.html
See also --proxy-insecure and --cacert.
I'm setting up a server with a couple of web services in Jboss 4.2.2. When I disable the SSL verification on the connector, all calls go through in SoapUI as well from a python script containing the same payload as the SoapUI script.
But when I enable the SSL verification with a connected keystore on the connector, all requests from SoapUI gets refused, with the following error:
Error getting response; org.apache.http.conn.HttpHostConnectException: Connection to https://1...8:2443 refused
My python-script still runs and successfully recieves the response as expected.
I have also linked the same keystore to the SSL settings in SoapUI, but without luck. I'm not familiar enough with SoapUI to know what I'm missing.
Anyone got an idea?
2443 isn't the default https connector port. Check it out on your server configuation. You can check the ports on which jboss is listening too using netstat, or directly use telnet to probe the connection.
I have a server running Rundeck to handle a large amount of various integration tasks.
The scheduled tasks each make a curl request to a given URL on our intranet system - essentially Rundeck just runs a temporary bash script.
About 99% of the time, this works fine - but we're seeing curl fail intermittently with Error 35: Unknown SSL protocol error in connection.
I've tried specifying the ssl protocol explicitly, with a known-good protocol, but we're still experiencing the issue.
We have a pretty high volume of requests going out - I'm not sure if that could have something to do with it. There is a chance we could have ~3 curl processes running at any given time.
Any advice would be appreciated.
curl --version
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
I've figured this out myself.
I ended up using wireshark to watch the communication on the server side of the SSL connection. The only anomaly I could see in the trace of the failures was that our Diffie-Hellman Public Key was 127 bytes, when typically it would be 128.
It looks like IIS didn't know how to handle this, and terminated the communication.
I'm not 100% clear on what the root cause of the issue was, but forcing a non-DH TLS cipher suite completely stopped the error messages.
Check This Article On Security.StackExchange For More Information
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