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: Michael via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 30 Jul 2026 19:23:12 +0500
>
> > 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.
>
>
RFC designation merely codifies protocol specifications; execution dictates
reality. Until code runs reliably in a production binary, a document is
static telemetry on a display. Protocol specifications do not route packets.
One example of poor specification: *HTTP/2 Server Push (RFC 7540)* was
fully specified, marketed as a performance breakthrough, and written into
standards. In production, it introduced cache race conditions, wasted
bandwidth, and created complex edge state management—ultimately leading
major client engines to deprecate and remove it entirely. An RFC existing
provides zero guarantee of long-term viability or sound architectural
design.
Hiding the Server Name Indication (SNI) from path-level network observers
simply redirects the telemetry vector to the central recursive resolver and
CDN ingress. Observation is not eliminated; it is concentrated.
Conflating browser-layer security models with programmatic transport
utilities like curl reflects a fundamental misunderstanding of operational
scope. Interactive browser sessions differ vastly from programmatic client
execution. A user-developer seeking true network privacy deploys encrypted
tunnels or virtual private overlays, securing the transport boundary in its
entirety while preserving the simplicity and predictability of the
underlying binary.
Injecting obscure DNS and TLS handshake mechanics into a foundational
network library trades architectural elegance for trivial obfuscation. As
for c-ares: requiring a specific asynchronous resolver to process HTTPS
resource records is an implementation bottleneck, not a validation of its
design. A user-developer choosing to link that dependency is simply
inheriting structural complexity.
Date: Thu, 30 Jul 2026 19:23:12 +0500
>
> > 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.
>
>
RFC designation merely codifies protocol specifications; execution dictates
reality. Until code runs reliably in a production binary, a document is
static telemetry on a display. Protocol specifications do not route packets.
One example of poor specification: *HTTP/2 Server Push (RFC 7540)* was
fully specified, marketed as a performance breakthrough, and written into
standards. In production, it introduced cache race conditions, wasted
bandwidth, and created complex edge state management—ultimately leading
major client engines to deprecate and remove it entirely. An RFC existing
provides zero guarantee of long-term viability or sound architectural
design.
Hiding the Server Name Indication (SNI) from path-level network observers
simply redirects the telemetry vector to the central recursive resolver and
CDN ingress. Observation is not eliminated; it is concentrated.
Conflating browser-layer security models with programmatic transport
utilities like curl reflects a fundamental misunderstanding of operational
scope. Interactive browser sessions differ vastly from programmatic client
execution. A user-developer seeking true network privacy deploys encrypted
tunnels or virtual private overlays, securing the transport boundary in its
entirety while preserving the simplicity and predictability of the
underlying binary.
Injecting obscure DNS and TLS handshake mechanics into a foundational
network library trades architectural elegance for trivial obfuscation. As
for c-ares: requiring a specific asynchronous resolver to process HTTPS
resource records is an implementation bottleneck, not a validation of its
design. A user-developer choosing to link that dependency is simply
inheriting structural complexity.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-07-30