Modify

Opened 3 years ago

Last modified 19 months ago

#19621 reopened defect

curl / polarssl handshake error

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Chaos Calmer 15.05
Component: base system Version: Trunk
Keywords: curl polarssl Cc:

Description

Trying to download a zeustracker domain blocklist with curl (ca-certificates installed) failed in cc:

curl -v https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
* ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF
curl: (35) ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF

Same download works fine with curl/debian:

curl -v https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
*   Trying 104.155.11.149...
* Connected to zeustracker.abuse.ch (104.155.11.149) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: *.abuse.ch (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: OU=Domain Control Validated,OU=PositiveSSL Wildcard,CN=*.abuse.ch
* 	 start date: Sun, 16 Mar 2014 00:00:00 GMT
* 	 expire date: Tue, 15 Mar 2016 23:59:59 GMT
* 	 issuer: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Domain Validation Secure Server CA
* 	 compression: NULL
* ALPN, server did not agree to a protocol
> GET /blocklist.php?download=domainblocklist HTTP/1.1
> Host: zeustracker.abuse.ch
> User-Agent: curl/7.42.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 08 May 2015 16:52:40 GMT
< Server: Apache/2
< X-Powered-By: PHP/5.5.9-1ubuntu4.9
< Content-Disposition: filename=zeus_domainblocklist.txt
< Strict-Transport-Security: max-age=31536000; includeSubDomains;
< Last-Modified: Fri, 08 May 2015 13:43:24 GMT
< Vary: Accept-Encoding
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block, 1; mode=block
< X-Frame-Options: sameorigin
< Transfer-Encoding: chunked
< Content-Type: text/plain
< 
[...]

Attachments (0)

Change History (37)

comment:1 Changed 3 years ago by hauke

  • Resolution set to worksforme
  • Status changed from new to closed

This works for me, you have to specify that you want to trust all certs if you do not have a certificate store installed.

root@OpenWrt:/# curl -v https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
* Error reading ca cert path /etc/ssl/certs - PolarSSL: (-0x2900) X509 - Read/write of file failed
curl: (77) Error reading ca cert path /etc/ssl/certs - PolarSSL: (-0x2900) X509 - Read/write of file failed
root@OpenWrt:/# curl -k -v https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
* Error reading ca cert path /etc/ssl/certs - PolarSSL: (-0x2900) X509 - Read/write of file failed
> GET /blocklist.php?download=domainblocklist HTTP/1.1
> User-Agent: curl/7.40.0
> Host: zeustracker.abuse.ch
> Accept: */*
> 
< HTTP/1.1 200 OK

Which OpenWrt version are you using?

comment:2 Changed 3 years ago by dibdot

Thanks for looking into this. I've done a retest with current snapshot and with ca-certificates installed ...

~# cat /etc/openwrt_release 
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r45945'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer r45945'
DISTRIB_TAINTS='no-all busybox'

Test with curl (still broken):

~# curl -v https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
* ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF
curl: (35) ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF

~# curl -V
curl 7.40.0 (mips-openwrt-linux-gnu) libcurl/7.40.0 PolarSSL/1.3.11
Protocols: file ftp ftps http https 
Features: IPv6 Largefile SSL 

Test with wget (works fine):

root@blackhole_ext1:~# wget -v https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
--2015-06-11 17:28:52--  https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
Resolving zeustracker.abuse.ch... 104.155.11.149
Connecting to zeustracker.abuse.ch|104.155.11.149|:443... connected.
HTTP request sent, awaiting response... 200 OK
[...]

So it's still an issue (at least for me).

comment:3 Changed 3 years ago by dibdot

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:4 Changed 3 years ago by dibdot

Other https connections are working fine (example for kernel.org), even with curl:

~# curl -v https://www.kernel.org/pub/site/sha256sums.asc
> GET /pub/site/sha256sums.asc HTTP/1.1
> User-Agent: curl/7.40.0
> Host: www.kernel.org
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 11 Jun 2015 15:43:24 GMT
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 1048
< Connection: keep-alive
< Last-Modified: Wed, 02 Apr 2014 07:50:45 GMT
< ETag: "418-4f60a8ac33f40"
< Accept-Ranges: bytes
< Strict-Transport-Security: max-age=15768000
< X-Frame-Options: DENY
< 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

17324d448888e8dae8a622f9a2fbf1cb6be408cb6bf9f2b1f3433d3d48d5a68c  README
d14ed8c7f39c2ef8c4f08581dfc9278c5b2bd20d07d70bb7ff4c3360833c2e35  sample_mirror_script.pl
-----BEGIN PGP SIGNATURE-----
[...]

But as I said in my first post, curl did work with debian ... so it seems to be an openwrt specific problem.

comment:6 Changed 3 years ago by chris5560

Last entry seems to be fixed. Missing certificate files.

comment:7 Changed 3 years ago by dibdot

Retested with a fresh build of r46484 ... error still persistent.

root@blackhole:~# curl -V
curl 7.43.0 (mips-openwrt-linux-gnu) libcurl/7.43.0 mbedTLS/1.3.11
Protocols: file ftp ftps http https 
Features: IPv6 Largefile SSL 
root@blackhole:~# curl -v https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
* ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF
curl: (35) ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF

comment:8 Changed 2 years ago by DeusExMachina

I tried to build Barrier Breaker 14.07 with polarssl and curl for the WGT634U as Legacy Unit. Does work, however, I get the same error described here, even though certificates are installed:

root@OpenWrt:/# curl -V
curl 7.38.0 (mipsel-openwrt-linux-gnu) libcurl/7.38.0 PolarSSL/1.3.9
Protocols: http https
Features: Largefile SSL

Error: "* ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF
curl: (35) ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF"

even if used with -k

Any Idea? And how about backporting the solution to the current stable release - please? :)

comment:9 Changed 2 years ago by dibdot

Retested with a fresh build of r46773 (incl. musl and mbedTLS-Update) ... error still persistent.

root@blackhole_ext1:~# curl -V
curl 7.43.0 (mips-openwrt-linux-gnu) libcurl/7.43.0 mbedTLS/1.3.12
Protocols: file ftp ftps http https 
Features: IPv6 Largefile SSL 
root@blackhole_ext1:~# curl -v https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
* ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF
curl: (35) ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF

comment:10 Changed 2 years ago by dibdot

Retested with current trunk - even the download with curl works quite fine.

Thanks a lot, ticket can be closed!

comment:11 Changed 2 years ago by nbd

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:12 Changed 2 years ago by dibdot

  • Resolution fixed deleted
  • Status changed from closed to reopened

Sorry, I have to reopen this ticket. Bug still exists on ar71xx devices (checked with wdr4300 and dir835), working now for raspi2 (bcm2709).

comment:13 Changed 2 years ago by anonymous

Also confirmed broken in trunk (DD) on Archer C7 v2.

comment:14 Changed 2 years ago by saidi

Same issue on trunk, fixed with:
opkg install ca-certificates

comment:15 Changed 2 years ago by anonymous

Still having the same issue trying to update now-ip, even with ca-certificates. ar71xx 15.05

comment:16 Changed 2 years ago by anonymous

Hello. I had similar problem with libcurl and polarssl without ca-certificates. I was using custom path with custom ca-bundle.crt.

curl_easy_setopt ( curl, CURLOPT_CAINFO, path );

But I've received error # 77 (Error: No such file or directory) from curl_easy_perform.

sudo mkdir -p /etc/ssl/certs

And the problem is fixed!

comment:17 Changed 2 years ago by dibdot

Retested with DD r48259, still broken on ar71xx devices like wdr4300 or dir835.

comment:18 Changed 2 years ago by anonymous

Still broken in r48648 on ar71xx device.

comment:19 Changed 2 years ago by wim@…

Still broken in r48973 ar71xx devices, like DIR-505

comment:20 Changed 23 months ago by wim@…

Curl still broken in r49037 for ar71xx devices like DIR-505.
With ca-certificates or just cacert.pem it just hangs forever in:
curl -u user:passw "https://now-ip.com/update?hostname=my.host.name"
Can someone please repair this?

comment:21 Changed 22 months ago by wim@…

Curl still broken in r49218 for ar71xx devices.

comment:22 Changed 21 months ago by Zak

Working in 15.05 (CC) on Archer C7 v2 (AC1750 Wireless Dual Band Gigabit Router).
I was able to resolve by installing certificates.
opkg install ca-certificates

comment:23 Changed 21 months ago by wim@…

The presence of ca-certificates is obvious, but it does not help on the ar71xx platform were stuff is broken op until now! (r49296).

comment:24 Changed 21 months ago by zloop

this might be a packaging issue/local setup issue

test run on WDR3600 ar71xx w. LEDE r278

root@OpenWrt:/tmp# curl -V
curl 7.48.0 (mips-openwrt-linux-gnu) libcurl/7.48.0 mbedTLS/2.2.1 libssh2/1.6.0
Protocols: file ftp ftps http https scp sftp 
Features: IPv6 Largefile SSL

adresses that fail (basically all):

curl -v https://www.tagesschau.de
curl  -v https://zeustracker.abuse.ch
curl -v https://www.howsmyssl.com/a/check

using certificate store does not work with mbedtls (curl/mbedtls will not build with the ca-path option)
so ca-certificates is not useful with mbedtls i think (it does not provide a single cert file)
using a cacert.pem file does work - from: https://curl.haxx.se/docs/caextract.html

now its working (and by adding certificates to cacert.pem):

curl --cacert /etc/ssl/cacert.pem  -v https://www.howsmyssl.com/a/check
curl --cacert /etc/ssl/cacert.pem  -v https://zeustracker.abuse.ch
curl --cacert /etc/ssl/cacert.pem  -v https://www.tagesschau.de
curl --cacert /etc/ssl/cacert.pem -v https://downloads.openwrt.org/chaos_calmer/15.05.1

comment:25 Changed 21 months ago by wim@…

Here I have (r49296): curl -V
curl 7.48.0 (mips-openwrt-linux-gnu) libcurl/7.48.0 mbedTLS/1.3.16
Protocols: file ftp ftps http https
Features: IPv6 Largefile SSL

ls -al /etc/ssl/cacert.pem
-rw-r--r-- 1 root root 252451 Mar 12 17:25 /etc/ssl/cacert.pem

curl --cacert /etc/ssl/certs/cacert.pem -v https://zeustracker.abuse.ch

  • ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF

curl: (35) ssl_handshake returned - PolarSSL: (-0x7280) SSL - The connection indicated an EOF

www.howsmyssl.com/a/check and www.tagesschau.de do answer a lot. (okay then?)

curl -u user:passw "​https://now-ip.com/update?hostname=my.host.name" just hangs forever.

With strace it always ends like this:
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
...
clock_gettime(CLOCK_REALTIME, {1463674522, 87186882}) = 0
write(3, "\26\3\1\0\225\1\0\0\221\3\3W=\346\232@I\367=\361X\244\315\205\243\363\337\34\205\20\244\236"..., 154) = 154
read(3, 0x57f088, 5) = -1 EAGAIN (Resource temporarily unavailable)
fcntl64(3, F_GETFL) = 0x82 (flags O_RDWR|O_NONBLOCK)
clock_gettime(CLOCK_MONOTONIC, {784055, 29300982}) = 0
clock_gettime(CLOCK_MONOTONIC, {784055, 30097275}) = 0
clock_gettime(CLOCK_MONOTONIC, {784055, 30436456}) = 0
poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {784055, 31297898}) = 0
clock_gettime(CLOCK_MONOTONIC, {784055, 31601424}) = 0
clock_gettime(CLOCK_MONOTONIC, {784055, 31923370}) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {784055, 34630073}) = 0
clock_gettime(CLOCK_MONOTONIC, {784055, 34988484}) = 0
clock_gettime(CLOCK_MONOTONIC, {784055, 35973807}) = 0
poll([{fd=3, events=POLLIN}], 1, 1000) = 1 ([{fd=3, revents=POLLIN}])
clock_gettime(CLOCK_MONOTONIC, {784055, 118187106}) = 0
clock_gettime(CLOCK_MONOTONIC, {784055, 118576402}) = 0
poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 1 ([{fd=3, revents=POLLIN|POLLRDNORM}])
read(3, "\25\3\3\0\2", 5) = 5
read(3, "\1p", 2) = 2

Where nothing ever follows.

comment:26 Changed 20 months ago by wim@…

Still broken in r49379 ar71xx devices, DIR-505.
Please get a free account at now-ip.com, it's really easy compared to no-ip.com. It's much harder to set up a platform to crosscompile 'everything' plus curl+openssl, just to discover that that wouldn't fit in the DIR505. It's still possible that the real problem lies at now-ip.com, but their contact addresses don't work and the only one that did work (via WHOIS) stays unanswered.
They require https with curl.
As an alternative, noip.com will work with http instead of https. But that doesn't resolve the bug.

comment:27 Changed 19 months ago by steve@…

Hi happy to look into this from Now-IP, we've not seen any reports to our support email addresses as far as I can see.

comment:28 Changed 19 months ago by wim@…

All at 18 feb 2016:
Curiously enough you mention two different contact addresses on your
home page. However, nothing would work.
Nothing but bounces from eforward3e.registrar-servers.com .
<contact@…>: unknown user: "contact@…"
<postmaster@…>: unknown user: "postmaster@…"
<support@…>: unknown user: "support@…"
<hostmaster@…>: unknown user: "hostmaster@…"

In the end I found an address in the whois database that worked:
Date: Thu, 18 Feb 2016 13:47:33 +0100
To: 6CBCC38B4AC644C48BEDC60376F21288.PROTECT@…
Subject: bug? and API updates

However, no reply either.

comment:29 Changed 19 months ago by steve@…

Hmm all addresses should be wild carded, I thought info@ was the only address listed on the site.

Any who, happy to help debug if needed.

comment:30 Changed 19 months ago by anonymous

It was not really a temporary problem, although it's different now.
No mail can get through. Qmail says now:
@40000000577833b2009d95cc delivery 599: deferral: 209.188.21.37_does_not_like_recipient./Remote_host_said:_451-131.180.127.155_is_not_yet_authorized_to_deliver_mail_from/451_<wim@…>_to_<steve@…>._Please_try_later./Giving_up_on_209.188.21.37./
@40000000577833b21378fe34 delivery 598: deferral: 209.188.21.37_does_not_like_recipient./Remote_host_said:_451-131.180.127.155_is_not_yet_authorized_to_deliver_mail_from/451_<wim@…>_to_<info@…>._Please_try_later./Giving_up_on_209.188.21.37./

comment:31 Changed 19 months ago by wim@…

I could try to remotely launch an API call, if that would help you to debug?

comment:32 Changed 19 months ago by steve@…

Sure, let me know source ip or some variable that you're setting so I can pick it out.

comment:33 Changed 19 months ago by wim@…

Request is now coming from 145.94.245.206

comment:34 Changed 19 months ago by wim@…

three times in a row.
Strace stops as previously posted.

comment:35 Changed 19 months ago by steve@…

Hmm,

The client established TCP multiple times but at least twice ended the connection without even attempting an SSL handshake.

Two of the connections did begin SSL negotiation, during one the client did not respond timely which caused a HTTP 408 after about 20 seconds, the server ended that session. The other time the client sent a RST after about 16 seconds.

comment:36 Changed 19 months ago by wim@…

Strange, isn't it?
The first attempt (before I announced the IP number) was from a machine behind the router and succeeded of course. Then three times from the the Dlink. All I can do is stop curl with Ctrl-C and restart it. So you might have seen twee shortish ones and a long one that I left alone for a while.
No difference at all on my side. Later I repeated another two times of which the last one still hangs.
No difference to be seen after all that time.

comment:37 Changed 19 months ago by anonymous

So curl doesn't notice that the connection has ended.
This is definitely wrong at the OpenWRT side then.
Let's hope the developers will do something about it then.
Thanks.

Add Comment

Modify Ticket

Action
as reopened .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.