I am trying to connect to server B from server A using curl (https). I have already tried with -k and it doesn't work.
I have looked into several posts and I spotted blog on this link but still issue exists.
When I do a curl from server A, I am getting following error:
* Rebuilt URL to: https://x.x.x.x:8443/
* Hostname was NOT found in DNS cache
* Trying x.x.x.x...
* Connected to x.x.x.x (x.x.x.x) port 8443 (#0)
* successfully set certificate verify locations:
* CAfile: /tmp/cert_test/certRepo
CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
curl: (35) error:140770FC:**SSL routines:SSL23_GET_SERVER_HELLO:**unknown protocol
I went on the server B (https://x.x.x.x:8443/) from the browser and downloaded the root, intermediate and the client certificate. As suggested in the blog, I have created a new folder and combined all the public certs into one directory and tried to execute the curl command
curl -v --cacert /tmp/cert_test/certRepo https://x.x.x.x:8443
I am getting GET_SERVER_HELLO:unknown protocol
any thoughts?
Curl version from the Client machine:
curl 7.37.0 (x86_64-suse-linux-gnu)
libcurl/7.37.0 OpenSSL/0.9.8j
zlib/1.2.7
libidn/1.10
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet
tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz
I am very sure the server is using TLSv1.2.
you did not post your curl/libssl version, but my best guess is that you're using an ancient build of a ssl/tls library, and/or an ancient version of curl which does not support whatever version of ssl/tls that server us ysubg. update your libssl and curl and try again. also post the output of curl --version.
PS, if you're on linux, you can get rough curl+openssl compile instructions here.
Related
The error is this:
* Connected to www.****.com (213.74.254.54) port 443 (#0)
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.2 (OUT), TLS alert, handshake failure (552):
* error:0A000152:SSL routines::unsafe legacy renegotiation disabled
* Closing connection 0
curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Same URL opens just fine on chrome. I tried to copy as curl from chrome and run using curl too, same error. So maybe somehow chrome is more slack on the SSL negotiation. How can I make curl behave the same?
curl version:
curl --version
curl 7.80.0 (x86_64-apple-darwin19.6.0) libcurl/7.80.0 OpenSSL/3.0.1 zlib/1.2.11 zstd/1.5.2 libidn2/2.3.2 libpsl/0.21.1 (+libidn2/2.3.2)
Release-Date: 2021-11-10
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IDN IPv6 Largefile libz NTLM NTLM_WB PSL SSL TLS-SRP UnixSockets zstd
I was having the same issues after upgrading to ubutun22 and openssl 3.0.2.
Using the steps by dave_thompson_085 with client pointing to a sect with the new option did not work for me. But adding the Options = UnsafeLegacyRenegotiation line to the system_default_sect at the bottom of the file did:
openssl_conf = openssl_init
[openssl_init]
ssl_conf = ssl_configuration
[ssl_configuration]
system_default = system_default_sect
[system_default_sect]
CipherString = DEFAULT:#SECLEVEL=2
Options = UnsafeLegacyRenegotiation
Meta: this isn't really programming or development; I will delete if necessary but I think superuser would be suitable and have voted for that (but we'll see what others think). I can see equally good arguments for apple.SX or security.SX instead, but (AFAIK) those would require a mod.
While Steffen is correct the server is either badly out of date or misconfigured and should be fixed, OpenSSL below 3.0.0 (just last year) by default will connect to a non-RFC5746 server as long as the server does not actually use the unsafe 'legacy' (RFC5246 et pred) renegotiation.
Thus if you can get/use a curl using older OpenSSL it should just work. I'm not sure what the situation is for Mac on this, for example if brew or fink or similar has this available. Worst case, both OpenSSL and curl are opensource so you could build your own older versions -- and that would be ontopic for SO, but a fair bit of work.
Alternatively, as long as curl doesn't work to mess it up (which I wouldn't expect, but don't know for sure), OpenSSL 1.1.0 up can control this with runtime configuration:
Either edit your systemwide config file openssl.cnf in the directory identified by openssl version -d (affects all programs and processes) or create your own file anywhere suitable and point to it with environment variable OPENSSL_CONF. See the man page for config(5) on your system or the web.
In the default section (beginning of the file to the first line wrapped in square brackets) add if not already present an item openssl_conf = sect1 where sect1 is conventionally openssl_init but can be any section-name unique in the file.
Create sect1 if not already present, and add if not already present an item ssl_conf = sect2 where sect2 is conventionally ssl_configuration but as above.
Create sect2 if not already present, and add if not already present an item client = sect3 where sect3 is conventionally client_tls_config but as above.
Create sect3 if not already present, and add if not already present an item for Options = whose value is (or is a comma-separated list including) UnsafeLegacyServerConnect. See the man page for SSL_CONF_cmd(3) on your system or the web.
When I try to execute this curl command :
curl -v --key some_key_file.key --cert certificate_file.pem --show-error --header "Content-Type: application/json;charset=UTF-8" https://some-api/service
I get the following error : curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
And the full execution log :
I have searched this error online and haven't found anyone explaining what it really meant.
Do you have any idea what the source cause could be ?
And do you know if there is a way to get more information about the error ?
Turns out the problem was with my curl version which, for some reason didn't accept the arguments --cert and --key.
To solve the problem, I installed a completely new curl version and ran it from the instllation folder and it worked.
Run the command from the path where you have curl package.
if you place in c:\curl goto this path and run the curl command it will work.
I also try installing latest curl (given below) but it didn't solve my issue.
curl 7.77.0 (x86_64-pc-win32) libcurl/7.77.0 OpenSSL/1.1.1k (Schannel)
zlib/1.2.11 brotli/1.0.9 zstd/1.5.0 libidn2/2.3.1 libssh2/1.9.0
nghttp2/1.43.0 libgsasl/1.10.0 Release-Date: 2021-05-26 Protocols:
dict file ftp ftps gopher gophers http https imap imaps ldap ldaps
mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli gsasl HSTS HTTP2 HTTPS-proxy IDN
IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI TLS-SRP
Unicode UnixSockets zstd
This error happens when you are behind a 7 layer firewall (i.e Palo Alto) that Allow SSL connections only via application, so you have to configure 2 rules in such solution.
Allow 443 or whatever port with higher priority
Allow Application SSL with lower priority
I'm on Windows 10 Professional Plus
I have a CURL command in DOS that works fine for standard FTP on Port 21
Once I'm in the folder C:\Program Files\cURL\bin> I issue the command:
curl -v -T (C:\folders\file_to_be_transferred.pdf) ftp://(username):(password)#(host.top_level_domain.com)/file_to_be_transferred.pdf
I'm trying to transfer the file using FTP over TLS. When I change FTP to FTPS and change the command to:
curl -v -T (C:\folders\file_to_be_transferred.pdf) ftps://(username):(password)#(host.top_level_domain.com)/file_to_be_transferred.pdf
I get the following response from CURL:
* Hostname was NOT found in DNS cache
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 999.999.999.999...
* Connected to host.top_level_domain.com (999.999.999.999) port 21 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files\cURL\bin\curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
When I request the CURL version using CURL -V I get the following response:
curl 7.39.0 (x86_64-pc-win32) libcurl/7.39.0 OpenSSL/1.0.1g zlib/1.2.8 WinIDN libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS IDN IPv6 Largefile SSPI SPNEGO NTLM SSL libz
How do I enable TLS over FTP with CURL on Windows 10?
Thanks for looking at this.
I resolved the problem. It was how I referenced the certificates. Earlier I had transferred the certificate generated by the FileZilla Server (certificate.crt) to the Windows Client. I placed that certificate file in the folder C:\Program Files\cURL\bin. Also, I copied the contents of certificate.crt and appended it to the existing certificate called curl-ca-bundle.crt. Appending the new certificate to that bundle file is very important. That was my problem. Now, when I reference only the FileZilla_Server generated certificate in the client's CURL command, the transfer works. It seems that cURL will always reference the curl-ca-bundle.crt file in addition to what is referenced in the command line. The logs referenced the details of the SSLv3 handshake. Also I restructured the command a little bit to make it more readable. Here it is:
curl --user username:password --cert "C:\Program Files\cURL\bin\certificate.crt" -v -T C:\folder_and_file_to_be_transferred.pdf ftps://host.top_level_domain.com/filename.pdf
By the way, the default port for FTPS is 990. On the router I had to open up port 990 and the port range 20101-20120. I did NOT have to open up port 21 since I was using ftpS.
I hope this helps someone else.
When I try to connect to any server (e.g. google.com) using curl (or libcurl) I get the error message:
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
Verbose output:
$ curl www.google.com --verbose
* Rebuilt URL to: www.google.com/
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,localaddress,.localdomain.com'
* Uses proxy env variable http_proxy == 'https://proxy.in.tum.de:8080'
* Trying 131.159.0.2...
* TCP_NODELAY set
* Connected to proxy.in.tum.de (131.159.0.2) port 8080 (#0)
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
* Closing connection 0
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number'
For some reason curl seems to use TLSv1.3 even if I force it to use TLSv1.2 with the command --tlsv1.2 (it will still print TLSv1.3 (OUT), ..."
I am using the newest version of both Curl and OpenSSL :
$ curl -V
curl 7.61.0-DEV (x86_64-pc-linux-gnu) libcurl/7.61.0-DEV OpenSSL/1.1.1 zlib/1.2.8
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy
I think this is a problem related to my installation of the programms.
Can somebody explain to me what this error message means?
* Uses proxy env variable http_proxy == 'https://proxy.in.tum.de:8080'
^^^^^
The https:// is wrong, it should be http://. The proxy itself should be accessed by HTTP and not HTTPS even though the target URL is HTTPS. The proxy will nevertheless properly handle HTTPS connection and keep the end-to-end encryption. See HTTP CONNECT method for details how this is done.
If anyone is getting this error using Nginx, try adding the following to your server config:
server {
listen 443 ssl;
...
}
The issue stems from Nginx serving an HTTP server to a client expecting HTTPS on whatever port you're listening on. When you specify ssl in the listen directive, you clear this up on the server side.
This is a telltale error that you are serving HTTP from the HTTPS port.
You can easily test with telnet
telnet FQDN 443
GET / HTTP/1.0
[hit return twice]
and if you see regular HTTP document here [not some kind of error], you know that your configuration is incorrect and the responding server is not SSL encrypting the response.
Simple answer
If you are behind a proxy server, please set the proxy for curl. The curl is not able to connect to server so it shows wrong version number.
Set proxy by opening subl ~/.curlrc or use any other text editor. Then add the following line to file:
proxy= proxyserver:proxyport
For e.g. proxy = 10.8.0.1:8080
If you are not behind a proxy, make sure that the curlrc file does not contain the proxy settings.
Also check your /etc/hosts file. Wasted 2 hours on this. If you have an url rerouted to 127.0.0.1 or any other loopback, this will fail the ssl handshake.
In my case the cause of this error was that my web server was not configured to listen to IPv6 on SSL port 443. After enabling it the error disappeared.
Here's how you do it for Apache:
<VirtualHost ip.v4.address:443 ip:v::6:address:443>
...
</VirtualHost>
And for nginx:
listen 443 ssl http2;
listen [::]:443 ssl http2;
Thanks to #bret-weinraub,
I found that something is weird about the server's reply. After a bit of investigation, it turned out that I have a static IP in /etc/hosts file for the target domain and as they have changed their IP address I'm not getting to the correct server.
More simply in one line:
proxy=192.168.2.1:8080;curl -v example.com
eg. $proxy=192.168.2.1:8080;curl -v example.com
xxxxxxxxx-ASUS:~$ proxy=192.168.2.1:8080;curl -v https://google.com|head -c 15 % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Trying 172.217.163.46:443...
* TCP_NODELAY set
* Connected to google.com (172.217.163.46) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
Another possible cause of this problem is if you have not enabled the virtual host's configuration file in Apache (or if you don't have that virtual host at all) and the default virtual host in Apache is only configured for non-SSL connections -- ie there's no default virtual host which can talk SSL. In this case because Apache is listening on port 443 the request for the virtual host that doesn't exist will arrive at the default virtual host -- but that virtual host doesn't speak SSL.
In the case of using MySQL CLI to connect to an external MySQL DB, depending on the version of MySQL, you can pass the --ssl-mode=disabled like:
$ mysql --ssl-mode=disabled -h yourhost.tld -p
Or simply in your client config, for example in /etc/my.cnf.d/client.cnf:
[client]
ssl-mode=DISABLED
This is for dev and sometimes security and these things can be forfeited in certain situations in a closed, private dev environment.
I have been using a curl command to get data from squareup.com:
curl -s -H "authorization: Bearer "xyz" https://connect.squareup.com/v1/me
This had been working correctly until last week, when it started to fail.
In working with my hosting company, it turns out they made a server change and had SSL proxy enabled on the server. Now when it runs I get the following error:
== Info: SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
== Info: Closing connection 0.
My curl is
$ curl --version
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29 libssh2/1.4.3 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: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP
Any idea how I can get curl to work with SSL proxy enabled on the server?