1850248 - Sites with invalid ECH records receive uninformative errors

Status: ASSIGNED

(Core :: Security: PSM, enhancement, P5)

Description

[Dennis Jackson]

When sites are misconfigured and are advertising ECH records with outer SNI names which they lack a valid certificate for, the current ECH spec states that the connection must fail:

Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using unencrypted ClientHellos, as this allows a network attacker to disclose the contents of this ClientHello, including the SNI.

So if ECH is not negotiated then we validate against the outer public name and throw up a certificate error page accordingly. However, this error page doesn't inform the user which name Firefox was validating the certificate against or that ECH was in play which makes for a confusing error page.

As an example where there is currently causing an issue in Firefox: https://checkout.ticketpro.ca/ which currently has a DNS record of :

checkout.ticketpro.ca.	300	IN	HTTPS	1 . alpn=h3,h2 ipv4hint=158.69.134.225 ech=AEX+DQBBWgAgACC8HVR3mYqI0E74kvwqK9TEYS53nfUUlN5rfA4hNQpeYwAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA=

The resulting error page is BAD_DOMAIN which is correct as it does not contain cloudflare-ech.com but looks confusing as the certificate is indeed valid for the domain the user is trying to navigate to.

We could look at improving this error page or at improving the spec so if ECH is not negotiated we accept either outer or inner SNI.

Comment 2

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

Attachment: Bug 1850248 - handle domain mismatch errors resulting from incorrect ECH configurations r?djackson!,gijs!