fix(DnsPinning): Ensure to always lookup based on FQDN

[DerDreschner]

• Resolves: [Bug]: App Updates with IPv6 and Debian Trixie: RequestException cURL error 60: SSL: no alternative certificate subject name matches target hostname 'github.com' #56489

Summary

After upgrading my private server from Debian 12 to Debian 13, I've experienced the same issue mentioned in #56489 which resulted in the app store to be totally unusable. Upgrading the Nextcloud version worked without any issues tho.

The investigation got the following results:

• The main issue is the DNS Pinning
• When looking up github.com, it tried to resolve A, AAAA and CNAME records
• It only got an A and AAAA record back
• The A record had the correct host and IP, but the AAAA record didn't. It was the result for proxy.fjygbaifeng.eu.org.dreschner.net
• cURL tries to connect via the (incorrectly) provided IPv6 address first
• The certificate doesn't match the expected hostname and resulting in the error 60

For reproducing the issue on command line level, you can use the following command on a server with IPv6 connectivity:

curl -v https://github.com/nextcloud-releases/integration_giphy/releases/download/v2.2.0/integration_giphy-v2.2.0.tar.gz --resolve 'github.com:443:140.82.121.4,2a0a:4cc0:c1:71d6:1876:e0ff:fe86:4038'

The reason is that we don't use FQDNs for resolving the DNS records and GitHub doesn't provide an AAAA record. Therefore, the program behind dns_get_records() looks for the host as subdomain of the local domain name. This works as I have a wildcard AAAA record set-up.

The fix is easy: just add a . at the end to make the requested domain name a FQDN and prevent the lookup under the local domain name when no record is being found in the first lookup.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[DerDreschner]

/backport to stable32

[DerDreschner]

/backport to stable33

[provokateurin]

Uh that is quite something 😅

[kesselb]

nit: @param/@return phpdoc comments are redundant with the type hints

[DerDreschner]

True, I have to figure out how to get PhpStorm to not do that when adding phpdoc comments.

[DerDreschner]

I've realized that my fix has an unexpected side effect. It totally prevents the usage of relative domains, as all domains are being treated as FQDNs from a DNS point of view. That's totally fine for the app store - but a bit unexpected for other developers and might break some apps, as it's usually possible to use both relative and absolute domains on any HTTP request. As most apps use our implementation, I lean on fixing it before someone might complain about it (and hence merging it into stable33 and stable32).

I can think of two ways to tackle that:

1. Put the list of IANA root zones into the resources folder (probably cache it for performance reasons) and check against that before marking the domain as an FQDN.
2. Rewrite the DNS pinning: Let cURL resolve the domain name, lookup the SOA record and then cache the result and inject it into any further request for the specified TTL.

The suggested change here to discard the record if it doesn't match the requested host would have the same unexpected side effect as my fix does. So, that solution is not possible, unfortunately. Also, as the example with proxy.fjygbaifeng.eu.org.dreschner.net demonstrates, we're unable to just check if the domain is likely a hostname (has no dot in it).

Any thoughts on this? @kesselb @provokateurin @ChristophWurst

[ChristophWurst]

Unfortunately I absolutely lack expertise in this area. I don't know.

[kesselb]

Rewrite the DNS pinning: Let cURL resolve the domain name, lookup the SOA record and then cache the result and inject it into any further request for the specified TTL.

I've looked into that a while ago, because resolving via curl would also address some issues in gated networks using proxies for outgoing connections, but it wasnt possible at this time.

Since PHP 8.4 we have https://www.php.net/manual/en/curl.constants.php#constant.curlopt-prereqfunction, that could work. However we have the connection established already, so not ideal either. Also not usable for us at the moment because PHP 8.4 or newer.

[DerDreschner]

I've looked into that a while ago, because resolving via curl would also address some issues in gated networks using proxies for outgoing connections, but it wasnt possible at this time.

Ohh, do you have more information about that for me?

I was looking into this during my vacation and it's possible with a little trick using the on_stats request option as being described here in 2018. I would guess that the mentioned CURLOPT_PREREQFUNCTION is just another way to access the information without using Guzzle.

Additionally, we only get the IP the connection is being established to. If there are multiple A / AAAA records, there is no way we can switch over in case of a failure. I wanted to make a test to see how browsers like Firefox handle that case to see if that is something I should really care about or can ignore safely with DNS Pinning (e.g., to prevent malicious redirects).

I was leaning towards the second option for that reason... But as there may be other features in the future we would have to implement ourself then as well, like DNS over TLS, I honestly don't like doing so.

[kesselb]

Case 1)

Private network. Outgoing connections are only possible through HTTP proxy. The nextcloud host could only resolve internal domain names through the DNS resolver. Hence the only option was to disable DNS pinning because we were unable to resolve external domain names. Requests themselves were possible because resolving did happen through the proxy.

Case 2)

#55847