Using --insecure and --ech hard together breaks

[Fullmetal5]

I did this

While playing around with an ECH enabled-build (ECH branch finally merged to OpenSSL master!) I noticed that if I happen to specify both --insecure and --ech hard to curl then the connection will always fail with an error about ECH getting a bad name.

In the process of reporting this I also noticed that --insecure breaks with --cert-status as well. Not sure if that's intentional or a bug as well.

Log:

./curl 'https://cloudflare-http3.com/cdn-cgi/trace' -v -s -o /dev/null --ech hard --doh-url https://one.one.one.one/dns-query --insecure
* !!! WARNING !!!
* This is a debug build of libcurl, do not use in production.
* alloc connection, bits.close=0
* setup connection, bits.close=0
* setup connection, bits.close=0
* new connection, bits.close=0
* Some HTTPS RR to process
* HTTPS RR: priority 1, target: .
* HTTPS RR: alpns 32 16 0 0
* HTTPS RR: no_def_alpn not set
* HTTPS RR: ipv4hints: len=8, val=6812021768120317
* HTTPS RR: ECHConfigList: len=71, val=0045fe0d00411a00200020a7501133ef883326bbacba5571cb6252fd747600ba555c991f3ba73f355a503e0004000100010012636c6f7564666c6172652d6563682e636f6d0000
* HTTPS RR: ipv6hint: len=32, val=2606470000000000000000006812021726064700000000000000000068120317
* Host cloudflare-http3.com:443 was resolved.
* IPv6: 2606:4700::6812:317, 2606:4700::6812:217
* IPv4: 104.18.2.23, 104.18.3.23
* QUIC is not supported in this build
*   Trying [2606:4700::6812:317]:443...
* ECH: ECHConfig from DoH HTTPS RR
* ECH: imported ECHConfigList of length 71
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1673 bytes data]
* SSL Trust: peer verification disabled
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [1210 bytes data]
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2555 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [78 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* ECH: result: status is bad name (unexpected), inner is cloudflare-http3.com, outer is cloudflare-ech.com
* ECH: ech-hard failed
*   Trying [2606:4700::6812:317]:443...
* ECH: ECHConfig from DoH HTTPS RR
* ECH: imported ECHConfigList of length 71
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1673 bytes data]
* SSL Trust: peer verification disabled
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [1210 bytes data]
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2555 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* ECH: result: status is bad name (unexpected), inner is cloudflare-http3.com, outer is cloudflare-ech.com
* ECH: ech-hard failed
* closing connection #0

I expected the following

I would expect that passing --insecure would not causing previously working ECH checks to fail.

curl/libcurl version

master (2862caf)

operating system

Arch (Linux 6.18.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Wed, 11 Feb 2026 16:48:28 +0000 x86_64 GNU/Linux)

[bagder]

specify both --insecure and --ech hard

I think this is what you ask for. --ech hard is documented: The connection fails if ECH is attempted but fails

--insecure tells curl to skip the certificate check. Slightly separate.

[bagder]

In the process of reporting this I also noticed that --insecure breaks with --cert-status as well

Can you please submit the details of that as a separate issue?

[Fullmetal5]

specify both --insecure and --ech hard

I think this is what you ask for. --ech hard is documented: The connection fails if ECH is attempted but fails

--insecure tells curl to skip the certificate check. Slightly separate.

In this case, the --insecure is causing the failure, if you try the command from the OP without --insecure it works fine, but with --insecure it fails.
Something about how curl/openssl is skipping the initial certificate check is causing the ECH to fail even when it should have succeeded.

In the process of reporting this I also noticed that --insecure breaks with --cert-status as well

Can you please submit the details of that as a separate issue?

Will do.

[Fullmetal5]

Ah, my "I expected the following" is inconsistent with what I reported.
While I did initially expect that passing --insecure would make ECH skip it's checks as well since they are based on the certificate, the bug report was really about the --insecure making the ECH check fail instead.
I will re-word this.

[bagder]

Oh ok, I misunderstood!

[icing]

Tried OpenSSL master branch with that command line, but while it accepts the ECH settings, it does not send an ECH ClientHello. Instead it crashes on SSL_free(ssl) at the end of the connection. Meh.

[bagder]

I can reproduce (after I applied #20797 to make it build correctly), but then I also found that this is a known bug/limitation of OpenSSL filed with them already back in September openssl/openssl#28609

[icing]

I made #20821 to work around OpenSSL reporting SSL_ECH_STATUS_BAD_NAME. I think this should be safe, but more eyes on this are very welcome.

[bagder]

@Fullmetal5 thoughts? does it makes your case work correctly?

[Fullmetal5]

@Fullmetal5 thoughts? does it makes your case work correctly?

Sorry for the late reply, yes that fixed the issue.

Thanks for the fix @icing