Re: HTTPS RR in curl

From: Niall O'Reilly via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 17 Apr 2025 16:08:03 +0100

Hey,

On 31 Mar 2025, at 8:43, Daniel Stenberg via curl-library wrote:

> Hey,
>
> I wrote a short blog post about HTTPS RR in curl:

Nice blog post!

I've just built from the master branch of the [curl/curl][] repo,
and had some surprises with ECH functioning (or not).
I'm wondering whether something isn't right, or rather that
I've overlooked something crucial.

I've prepared by building an [ECH-aware fork][] of OpenSSL, and
installing the built files under a convenient prefix. I've also
set up a local instance of unbound as my system resolver, whose
query logging I can enable or disable as needed.

I've then built curl using the following configuration options:

```
    --disable-shared
    --enable-debug
    --enable-maintainer-mode
    --enable-ech
    --with-openssl=/home/vagrant/installed/defo-project
    --with-openssl_rpath=auto
```

Testing the resulting executable against https://test.defo.ie,
which provides dynamic content to indicate whether ECH was
attempted and successful, gave the following results.

Without DoH, and with `--ech ecl:<BASE64BLOB>` — ECH succeeds.

Without DoH, and with `--ech true`, my resolver logs NO request
for the HTTPS RR, and curl gives the message
`ECH: requested but no ECHConfig available`.

With DoH, and with `--ech true`, my resolver logs an request
for the HTTPS RR, but curl gives the message
`ECH: requested but no ECHConfig available`.

The second and third results were surprises.

For the second one, I had expected that configuring
`--enable-httpsrr` (either explicitly, or as an effect
of configuring `--enable-ech`) would cause the inclusion
of code for a "complementary" request for an HTTPS RR
(using c-ares), in addition to the usual address resolution
using *getaddrinfo()*.

However, the resolver log shows no such request.

I have tried adding `--enable-httpsrr` explicitly as a
configuration option, and observed the same behaviour.

For the third case, although resolver logs show a request
for the relevant HTTPS RR, the corresponding
`struct Curl_dns_entry` fetched by *Curl_ossl_ctx_init()*
lacks the relevant data.

I suspect that this may be due to a race condition, as
code in *lib/doh.c* seems to unlock the cache object after
adding the address information, and later adds information
from the HTTPS RR (without locking the cache object).

I think the cache object should better be populated
atomically under lock with both pieces of information.

Have I made some silly mistake, or should I open an
issue or two?

Niall

---
[curl/curl]:
https://github.com/curl/curl
[ECH-aware fork]:
https://github.com/defo-project/openssl

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2025-04-17