| Summary: | wget TLS handshake failure (alert code 40) | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | macmpi <spam> |
| Component: | Networking | Assignee: | 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
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? 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? berryboot release binaries for Pi can be found here: https://sourceforge.net/projects/berryboot/files/ 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. 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? (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. 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) 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. (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... (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 ? (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. 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
(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) 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. (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. (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. 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
(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. Indeed. Fixing. Try current git. (In reply to Denys Vlasenko from comment #19) is.gd OK again now, but ftp.openbsd.org still fails I'm afraid. Found the bug. Ok, try now. (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. |