Unable to establish SSL connection with the website when ECH is enabled
Categories
(Core :: Networking: DNS, defect)
Tracking
()
People
(Reporter: jsnjack, Unassigned)
Details
Attachments
(1 file)
6.81 KB,
application/x-pcapng
|
Details |
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•25 days ago
|
||
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•25 days ago
|
||
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)
Reporter | ||
Comment 3•25 days ago
|
||
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•25 days ago
|
||
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>
?
Reporter | ||
Comment 5•25 days ago
|
||
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
Reporter | ||
Comment 6•25 days ago
|
||
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•25 days ago
|
||
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").
Reporter | ||
Comment 8•25 days ago
|
||
Well.. xx.internal it is! :D
Thanks Dana for shining some light on it!
Comment 9•24 days ago
|
||
This looks like not a Firefox bug, so I'll just close this.
Description
•