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
