CURL download errors with BanIP and libmbedtls ver 3.6.6-r1

Installing and Using OpenWrt
1

I'm not sure if this issue should be directed at mbedtls maintainer(s), BanIP maintainer @dibdot, or if it interests both.

I have a confirmed issue and workaround using two identical devices; both on 25.12.2 stable, but on different libmbedtls versions.

Device 1 (working with no issues): libmbedtls21 3.6.5-r1
Device 2 (curl download issues): libmbedtls21 3.6.6-r1

During BanIP startup, downloading the Countryv4 lists from ipdeny . com, this error:
image

From affected device 2, I use the command line to try and mimic download process and get more information.

image

Wondering if it is a TLS 1.2 / 1.3 conflict with the website, I try again from Device2 specifying to only use TLS 1.2. This time it succeeds.

image
image899×141 14.7 KB

I'm not a developer - so not sure if the actual fix would be to alter mbedtls package to do some type of additional TLS version check / 1.2 fallback logic, or if BanIP should be modified to use 'curl' with TLS 1.2 when downloading lists from ipdeny . com

If I should open a report on Github for this, please advise. Thank you.

BTW - I know ideally this is something that could / should / would be fixed by the website owner of ipdeny . com. This is however a situation that could potentially occur with numerous other sites out there.

2

Thanks, seems to be a regression in libmbedtls then (fyi @hauke). I would open an issue at

In the meantime you could use "insecure downloads" option in banIP.

Edit: Sorry, this won't help with TLS handshake errors.

3

I've written a small TLS version check for ipdeny.com:

#!/bin/sh

for v in tls1 tls1_1 tls1_2 tls1_3; do
    printf '%-8s: ' "$v"
    if echo | openssl s_client -connect www.ipdeny.com:443 -servername www.ipdeny.com -"$v" 2>/dev/null | grep -q "Cipher.*: [^ ]"; then
        echo "supported"
    else
        echo "not supported"
    fi
done

Result:

root@blackhole:~# ./test.sh 
tls1    : not supported
tls1_1  : not supported
tls1_2  : supported
tls1_3  : not supported

The test shows that the server doesn't support 1.3 at all — suggesting a fallback bug rather than a genuine 1.3 issue. But that's only an educated guess ... :wink:

4

I think I've found the culprit:

root@blackhole:~# openssl s_client -connect www.ipdeny.com:443 -servername www.i
pdeny.com -tls1_2 -sigalgs 'RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512' </dev/
null 2>&1 | grep -iE "peer sign|signature|cipher"
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

There is an open PR to fix an issue with the above ServerKeyExchange signature ...

So no TLS fallback error, "just" a TLS 1.2 regression.

5

Thank you Dirk! I appreciate you finding both the issue and that there is a solution in the works. :smiley:

6

Thx for your support @JustAnotherEndUser…and I thought i would be….:rofl:

7

Do we know when this fix will be available for 25.12.2? I tried digging though github but I was unable to figure out the status myself.

8

Keep running owut check -v until you see it. Once/twice a day should be fine. When it becomes available upgrade with owut upgrade

9

Thanks. I’ve been doing that, but that’s not what I want to do. I rather be able to check somewhere to see it’s status or what it is waiting on.

10

Can't still don't see any update on owut. (Have I to hurry?)
I'm on Snapshot build.

11

https://github.com/openwrt/openwrt/commits/openwrt-25.12/ - there are no mbedtls commits to compile.

12

Regarding this it has been merged.

13

This is not the openwrt project, you can find the openwrt package here. It is upstream, which means your link is in the github repository of mbedtls itself. Currently it is only in github and openwrt does rely on releases. The last release is 3.6.6, which fixed some security issues. I think we have to wait for a future release 3.6.7 to get this bugfix in openwrt. Then the makefile of openwrt can be updated to this future release.

Disclaimer: it is possible to define a different source than a tar ball, e.g. a direct git commit. But I highly doubt that this will happen, as mbeltls is a central package and it would complicate versioning and therefore debugging if necessary.

14

I thought it was merged. Problem from this thread error code 35 from
Curl when tried to update ddns provider.

This is from BanIP thread

I read this from 'newsense'

15

@octopus - Not sure if you saw this post, but for DDNS, you can workaround with TLS 1.2 until updated mbedtls package is available.

16

Guess I need to dig out my 24.10.x backup and run it for now. I don’t want to do without country blocklists for an extended amount of time.

17

I only mentioned how to get it whenever it becomes available—-if not part of a 25.12.x maintenance release.

I’ve no insight on whether mbedtls project will patch v3.6.6 or if we have to wait for the next release whenever that may happen

18

I'm sorry then I completely misunderstand this:

The changes in upstream were merged today, somebody needs to bump the openwrt version in main and 25.12. I would do it, but my last try to be active on github ended not so good (I never was before)...

I saw that, but not sure where to put it in ddns updater.

My impression was it would be fixed and push upstream for a update.
I have to wait until 25.12.3 is released and hope it fixed.

19

I submitted a PR to backport to OpenWrt the upstream mbedTLS commits that fix this issue. mbedtls: backport upstream patches to fix TLS 1.2 client issues #23066

If it is merged as-is there will be a libmbedtls-3.6.6-r2 that you can update to.

20

I can't still not se any updated libmbedtls-3.6.6-r2 when using owut with build snapshot.
I'm not sure how things suppose to work in this case.
Can someone throw some ight on this, thanks.