armhf: buster: TLS / HTTPS partly broken
Hi,
I am building Docker images for amd64, armhf, and arm64. I have a very
simple container based on debian:buster where curl works fine on amd64
and arm64 but fails on armhf [1]. This makes it very easy to reproduce
the problem.
# curl --version
curl 7.64.0 (arm-unknown-linux-gnueabihf) libcurl/7.64.0
OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2
(+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM
NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
# curl https://www.google.com
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
The error occurs on a real armhf target (Raspberry Pi 3) as well as
with QEMU (tested with
3.1.0-2 and v4.2.0-7).
The error cannot be reproduced with debian:stretch. [2]
The error cannot be reproduced with ubuntu:bionic or ubuntu:focal. [3]
With wget it works fine. None the less, I doubt that curl itself it
the source of the problem. The Logitech Media Server package [4] (not
an official Debian package) shows the problem as well. LMS is written
using Perl (mainly) and does not use curl.
I also gave aria2 a try. It downloads but gives a warning on armhf.
# aria2c https://www.google.com
[..]
05/03 12:32:37 [WARN] aria2c had to connect to the other side using an
unknown TLS protocol. The integrity and confidentiality of the
connection might be compromised.
Peer: www.google.com (216.58.207.164:443)
Does that mean a TLS library does not feature all required protocols on armhf?
Does anybody have an idea what the problem might be? Who can / should
tackle the problem?
I did not report the problem using reportbug because I have no clue
which package is causing the problem.
Greetings,
Mark
[1] https://gitlab.com/toertel/docker-image-tls-https-broken
[2] https://gitlab.com/toertel/docker-image-tls-https-broken/pipelines/141798495
[3] https://gitlab.com/toertel/docker-image-tls-https-broken/pipelines/141820625
[4] http://downloads.slimdevices.com/LogitechMediaServer_v7.9.2/
Reply to: