Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: HTTPS-RR and ECH
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stephen Farrell <stephen.farrell_at_cs.tcd.ie>
Date: Thu, 30 Jul 2026 12:26:34 +0100
Hiya,
On 30/07/2026 12:11, Daniel Stenberg via curl-library wrote:
> On Thu, 30 Jul 2026, Michael wrote:
>
>>> We want ECH enabled to push online privacy forward.
>
>> Their proposal assumes that relocating network visibility translates
>> to eliminating it. In reality, Encrypted Client Hello (ECH) merely
>> shifts domain-name exposure from a local internet service provider to
>> a centralized CDN edge—such as Cloudflare.
>
> It's more than a proposal. ECH is defined in RFC 9849. It's live and in
> use.
>
> It hides the SNI from passive network snoopers. I think that's a good
> step forward.
ECH was also part of the OpenSSL 4.0 release back in April this
year, so no longer needs a special OpenSSL fork.
>
>> i do not agree with c-ares project, so will see imploding it only as a
>> net negative event.
>
> I don't know what that means, but to me that is irrelevant here. c-ares
> is the only way curl can resolve HTTPS records until someone adds
> support for another DNS library, but then I would also love to learn why
> that other library is better for this purpose.
>
> It is up to everyone who builds curl to decide wether to use c-ares or not.
I don't think c-ares is always required for HTTPSRR/ECH - if DNS
queries are configured to use DoH, then HTTPSRR will also work
fine IIUC.
Cheers,
S.
Received on 2026-07-30
Date: Thu, 30 Jul 2026 12:26:34 +0100
Hiya,
On 30/07/2026 12:11, Daniel Stenberg via curl-library wrote:
> On Thu, 30 Jul 2026, Michael wrote:
>
>>> We want ECH enabled to push online privacy forward.
>
>> Their proposal assumes that relocating network visibility translates
>> to eliminating it. In reality, Encrypted Client Hello (ECH) merely
>> shifts domain-name exposure from a local internet service provider to
>> a centralized CDN edge—such as Cloudflare.
>
> It's more than a proposal. ECH is defined in RFC 9849. It's live and in
> use.
>
> It hides the SNI from passive network snoopers. I think that's a good
> step forward.
ECH was also part of the OpenSSL 4.0 release back in April this
year, so no longer needs a special OpenSSL fork.
>
>> i do not agree with c-ares project, so will see imploding it only as a
>> net negative event.
>
> I don't know what that means, but to me that is irrelevant here. c-ares
> is the only way curl can resolve HTTPS records until someone adds
> support for another DNS library, but then I would also love to learn why
> that other library is better for this purpose.
>
> It is up to everyone who builds curl to decide wether to use c-ares or not.
I don't think c-ares is always required for HTTPSRR/ECH - if DNS
queries are configured to use DoH, then HTTPSRR will also work
fine IIUC.
Cheers,
S.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature