1931335 - Unable to establish SSL connection with the website when ECH is enabled

Status: RESOLVED INVALID

(Core :: Networking: DNS, defect)

Description

[Yauhen Shulitski]

Attachment: exported.pcapng

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:

I have haproxy (doesn't support ECH) which handles SSL termination for 3 different domains. When ECH is enabled, firefox sends the request with SNI=cloudflare-ech.com. Haproxy is unable to correctly match the certificate and returns the wrong one.

Actual results:

Haproxy is unable to correctly match the certificate and returns the wrong certificate. SSL connection can't be established.

Expected results:

Since HAProxy doesn’t yet support ECH, it shouldn’t be used in this case. How does Firefox determine when to use ECH and when not to? I use the same HAProxy configuration for different servers, and sometimes it sends an ECH request, and other times it doesn’t.

I’ve attached the related network packets, in case they’re helpful.

I believe the issue started occurring after upgrading to version 132.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler]]

If your server doesn't support ECH, you probably shouldn't advertise support for it in your DNS records. It looks like you're using Cloudflare - can you turn it off in your Cloudflare settings? (https://developers.cloudflare.com/ssl/edge-certificates/ech/#enable-ech)

Comment 3

[Yauhen Shulitski]

I'm not using Cloudflare. The request is forwarded to a local haproxy. DNS resolution is done by a local dnsmasq instance. Self-signed certificate is used.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler]]

In that case, it looks like your dnsmasq is configured to advertise ECH support. What do you get when you run dig +short -t TYPE65 <your domain>?

Comment 5

[Yauhen Shulitski]

That's interesting! I think I might know why is that happening. In my previous message, I mentioned that this is happening for a domain which resolves to my local IP (lxd container, which runs haproxy with 3 different domains, all self-signed). The domain in question is xx.net (just a random short domain). So happens, that there is indeed a real public website under this domain!

$ dig +short A xx.net @1.1.1.1 
104.21.7.165
172.67.130.87

And 104.21.7.165 IP address belongs to Cloudflare.

$ dig +short -t A xx.net
10.162.217.102

$ dig +short -t TYPE65 xx.net
1 . alpn="h3,h2" ipv4hint=104.21.7.165,172.67.130.87 ech=AEX+DQBBNQAgACBIz/ryBqgZzphb7QRAOU4D49st5TEKVDYUAdgzegyMUQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3034::6815:7a5,2606:4700:3035::ac43:8257

Comment 6

[Yauhen Shulitski]

The issue seems to be related to my dns resolver, dnsmasq. Adding this line to it's configuration file

dns-rr=xx.net,65,

results in

$ dig +short -t TYPE65 xx.net
;; Warning: Message parser reports malformed message packet.

which resolves the issue

I wonder, how Chrome was able to correctly detect that my instance of xx.net doesn't support ECH?

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler]]

They may have some sort of fallback mechanism that Firefox doesn't. In any case, this seems to be more of a DNS issue (and the answer may well be "don't re-use a public domain name you don't own for your private infrastructure").

Comment 8

[Yauhen Shulitski]

Well.. xx.internal it is! :D

Thanks Dana for shining some light on it!

Comment 9

[Kershaw Chang [:kershaw]]

This looks like not a Firefox bug, so I'll just close this.