Bug 11456

Summary: wget TLS handshake failure (alert code 40)
Product: Busybox Reporter: macmpi <spam>
Component: NetworkingAssignee: unassigned
Status: RESOLVED FIXED    
Severity: normal CC: busybox-cvs
Priority: P5    
Version: 1.29.x   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
Host: Target:
Build:

Description macmpi 2018-10-30 10:41:05 UTC
I’m having an issue with several redirections using latest busybox wget (built as of https://github.com/maxnet/berryboot on Pi device)to access some content.
Similar issues have been documented in:
https://github.com/mirror/busybox/issues/6


For instance with a popular redirector (invoqued from berryboot console):
# wget https://is.gd/InstLk
Connecting to is.gd (104.31.15.172:443)
wget: note: TLS certificate validation not implemented
wget: TLS error from peer (alert code 40): handshake failure
wget: error getting response: Connection reset by peer

Whereas the target link gets downloaded fine directly:
# wget https://raw.githubusercontent.com/macmpi/berryboot-scripts/master/Lakka/installLakka
Connecting to raw.githubusercontent.com (151.101.120.133:443)
wget: note: TLS certificate validation not implemented
installLakka         100% |********************************| 10077  0:00:00 ETA

So something seems to get wrong in the redirection process, which seems to break with busybox wget.
These issues do not show-up in GNU wget (Debian Stretch / Ubuntu 18.04)

Unsure if this wold be failing SNI support or else: happy to provide more traces if directed to. This is easily replicable using Berryboot console.
Comment 1 Denys Vlasenko 2018-10-30 16:24:33 UTC
Can't reproduce on current git.

Can you reproduce this on current git?

If yes: does it also happens on x86 with the .config similar to one you use on your Pi device?
Comment 2 macmpi 2018-10-30 16:43:25 UTC
Hi.
Unfortunately I'm not building it myself: you may find config here:
https://github.com/maxnet/berryboot/blob/berryboot2018/buildroot-2018.08/package/busybox/busybox.config

I think it is built without SSL library, but in compatibility mode.
Maybe the issue only shows-up in that mode?
Comment 3 macmpi 2018-10-30 21:53:05 UTC
berryboot release binaries for Pi can be found here:
https://sourceforge.net/projects/berryboot/files/
Comment 4 macmpi 2018-11-01 18:04:57 UTC
Hi Denys

I can confirm I can reproduce exact same problem from current git, on x86.
Here is how:
git clone https://git.busybox.net/busybox
cd busybox
make allnoconfig
make menuconfig
select Networking/wget app and all its sub-sections, EXCEPT "Try to connect to HTTPS using openssl"
make

Then the same testcases will work/fail.
If I re-enable "Try to connect to HTTPS using openssl" then it all work.

So something gets wrong when not using openssl option code path...

Thanks for your feedback.
Comment 5 macmpi 2018-11-02 18:21:47 UTC
Quickly looking at the code, it seems SNI is only implemented in spawn_https_helper_openssl (if ENABLE_FEATURE_WGET_OPENSSL is set).

That could be causing the issue with servers requiring SNI, and wget not compiled with openssl (to save space).

Any thought?
Comment 6 Denys Vlasenko 2018-11-04 17:34:20 UTC
(In reply to macmpi from comment #5)
> That could be causing the issue with servers requiring SNI, and wget not compiled with openssl (to save space).

No, SNI is rather trivial to implement and it _is_ implemented in bbox TLS code. Otherwise, wget-ting from every multi-hostname site wouldn't work.

The issue seems to be that this particular server only accepts ciphers from ECDHE_ECDSA_foo family.
Comment 7 Denys Vlasenko 2018-11-04 18:56:41 UTC
The commands I tried:

openssl s_client -connect is.gd:443 -debug -no_ticket -cipher DHE-RSA-CHACHA20-POLY1305
- not accepted (cipher id ccaa)

openssl s_client -connect is.gd:443 -debug -no_ticket -cipher ECDHE-RSA-CHACHA20-POLY1305
- not accepted (cipher id cca8)

openssl s_client -connect is.gd:443 -debug -no_ticket -cipher ECDHE-ECDSA-CHACHA20-POLY1305
- accepted (cipher id cca9)

openssl s_client -connect is.gd:443 -debug -no_ticket -cipher ECDHE-ECDSA-AES128-SHA
- accepted (cipher id c009)

openssl s_client -connect is.gd:443 -debug -no_ticket -cipher ECDHE-ECDSA-AES128-GCM-SHA256
- accepted (cipher id c02b)
Comment 8 macmpi 2018-11-04 20:18:41 UTC
Thanks for the feedback.

I assume you could replicate the issue as per comment #4.
Do you have same symptom/diagnostic with the other exemple from original github issue?
https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.6.4.tar.gz

Any chance wget can be fixed to connect & download such sample URL & re-directors, with only TLS option (without openssl option)?

Thanks.
Comment 9 Denys Vlasenko 2018-11-05 18:45:05 UTC
(In reply to macmpi from comment #8)
> Any chance wget can be fixed

This will require implementing elliptic curve crypto. This is definitely not a one-liner fix...
Comment 10 macmpi 2018-11-06 18:58:16 UTC
(In reply to Denys Vlasenko from comment #9)
>This will require implementing elliptic curve crypto.
Ouch... Thanks a lot for looking into it: appreciate all that hard work.

What are the specific ciphers that current Busybox TLS implementation supports? Are some supposed to be mandatory baselines in TLS 1.2/1.3 ?
Comment 11 Denys Vlasenko 2018-11-07 21:30:56 UTC
(In reply to macmpi from comment #10)
>What are the specific ciphers that current Busybox TLS implementation supports? 

AES128 and 256, SHA1 and 256, certs with RSA public key

>Are some supposed to be mandatory baselines in TLS 1.2/1.3?

Well, the problem is, as weaknesses are found, weaker crypto setups gets "discouraged" by newer RFCs and newer versions of software - even if these same setups were deemed as "required to be supported" by initial RFCs. End result is, some "required to be supported" things may well end up not being supported by a significant fraction of servers.
Comment 12 Denys Vlasenko 2018-11-13 11:01:18 UTC
Fixed in git:

commit bddb6545a982696bde417a9ae621f9e2d3c22b3d
Date:   Tue Nov 13 02:16:24 2018 +0100

    tls: add support for ECDHE-ECDSA-AES-128-CBC-SHA and x25519 curve
Comment 13 macmpi 2018-11-13 19:13:30 UTC
(In reply to Denys Vlasenko from comment #12)
Thanks a lot for the fix, works fine for is.gd now.
Looking forward next stable release then.


There's still an issue with the other example download:
https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.6.4.tar.gz
Is downloaded fine with GNU wget, or with latest git busybox wget with SSL, but

with latest git (TLS only), download fails and output is now:
./busybox wget https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.6.4.tar.gz
Connecting to ftp.openbsd.org (129.128.5.191:443)
wget: note: TLS certificate validation not implemented
wget: TLS error from peer (alert code 40): handshake failure
wget: error getting response: Connection reset by peer

(last message is new)
Comment 14 Denys Vlasenko 2018-11-14 17:29:57 UTC
openssl s_client -connect ftp.openbsd.org:443 -debug -no_ticket ...

-cipher ECDHE-RSA-AES256-GCM-SHA384: yes
-cipher ECDHE-RSA-AES128-GCM-SHA256: yes
-cipher ECDHE-RSA-AES128-SHA256: no
-cipher ECDHE-RSA-AES128-SHA: no
-cipher ECDHE-RSA-AES256-SHA: no
-cipher AES256-CCM8: no
-cipher AES128-GCM-SHA256: no
-cipher ECDHE-ECDSA-AES128-GCM-SHA256: no

-cipher ECDHE-RSA-CHACHA20-POLY1305: yes
-cipher ECDHE-ECDSA-CHACHA20-POLY1305: no

-cipher ECDHE-ARIA256-GCM-SHA384: no
-cipher DHE-RSA-AES128-GCM-SHA256:no

Evidently, it only supports ECDHE-RSA-AESnnn-GCM-SHAnnn and ECDHE-RSA-CHACHA20-POLY1305.
Comment 15 macmpi 2018-11-14 21:21:11 UTC
(In reply to Denys Vlasenko from comment #14)
Thanks for considering extending the number of supported ciphers.

Would it make sense to refine the error message for such similar issues with something like "unsupported cipher" rather than general consequential "handshake failure"/"Connection reset by peer"?
This may help other users to diagnose better & report accordingly in the future.

Thanks again for all your efforts.
Comment 16 Denys Vlasenko 2018-11-20 16:09:03 UTC
(In reply to macmpi from comment #15)
> Would it make sense to refine the error message for such similar issues with something like "unsupported cipher" rather than general consequential "handshake failure"/"Connection reset by peer"?

Remote does not tell us that information. It can only be inferred by trying different ciphers with e.g. openssl.
Comment 17 Denys Vlasenko 2018-11-23 18:48:50 UTC
Fixed in git:

commit 83e5c627e1b2c7f34d694696d0c3d5a3ce25dc59
Date:   Fri Nov 23 17:21:38 2018 +0100

    tls: add support for TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher
Comment 18 macmpi 2018-11-24 09:09:57 UTC
(In reply to Denys Vlasenko from comment #17)
Thanks for this.

However I just tried with current git, with the same 2 test cases, and both fail the same way:
./busybox wget https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.6.4.tar.gz
Connecting to ftp.openbsd.org (129.128.5.191:443)
wget: note: TLS certificate validation not implemented
wget: TLS error from peer (alert code 20): bad MAC
wget: error getting response: Connection reset by peer

./busybox wget https://is.gd/InstLk
Connecting to is.gd (104.31.15.159:443)
wget: note: TLS certificate validation not implemented
wget: TLS error from peer (alert code 40): handshake failure
wget: error getting response: Connection reset by peer

That latter one was working before last round of changes.
Both cases work fine if libSSL is enabled.

Note there a a few warning during make:
applets/usage.c: In function ‘main’:
applets/usage.c:52:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
   write(STDOUT_FILENO, usage_array[i].usage, strlen(usage_array[i].usage) + 1);

applets/usage_pod.c: In function ‘main’:
applets/usage_pod.c:74:3: warning: format not a string literal and no format arguments [-Wformat-security]
   printf(usage_array[i].aname);

networking/wget.c: In function ‘retrieve_file_data’:
networking/wget.c:1011:4: warning: ignoring return value of ‘ftruncate’, declared with attribute warn_unused_result [-Wunused-result]
    ftruncate(G.output_fd, pos);

Thanks.
Comment 19 Denys Vlasenko 2018-11-24 20:39:59 UTC
Indeed.
Fixing.
Try current git.
Comment 20 macmpi 2018-11-24 22:25:25 UTC
(In reply to Denys Vlasenko from comment #19)
is.gd OK again now, but ftp.openbsd.org still fails I'm afraid.
Comment 21 Denys Vlasenko 2018-11-24 23:54:23 UTC
Found the bug.
Ok, try now.
Comment 22 macmpi 2018-11-25 12:01:22 UTC
(In reply to Denys Vlasenko from comment #21)
OK, current git seems just perfect! Hats-off.
Only tested on x86 so far, with "usual suspects" URLs: I guess will be fine on Pi now.

Thanks a lot for all the hard work.
Looking forward next stable release.