User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Enable network.dns.echconfig.enabled on Nightly, and test ECH with https://crypto.cloudflare.com/cdn-cgi/trace.

Actual results:

I randomly get either :

• http=http/1.1 sni=encrypted
• http=http/2 sni=plaintext

Wireshark shows two ClientHello (less than 10ms apart) :

• ALPN=h2,http/1.1 SNI=crypto.cloudflare.com
• ALPN=http/1.1 SNI=cloudflare-esni.com ECH extension (0xfe0d)

Expected results:

All requests to servers supporting ECH (draft 13) should use it.

Kershaw, can you take a look?

So, when Firefox tries to connect to crypto.cloudflare.com, it creates a speculative connection and also does a DNS lookup for retrieving ECH.
When the speculative connection is established before ECH is available, Firefox uses the speculative connection without waiting for ECH.
I think we should make sure that we always wait for ECH when network.dns.echconfig.enabled is enabled.

So I suppose on the DNS side, the A/AAAA requests are done before the HTTPS one, or they complete earlier, allowing the speculative connection to be created without the ECH configuration (despite network.dns.force_waiting_https_rr ?).

There is network.dns.use_https_rr_for_speculative_connection too, but enabling it doesn't solve the issue.

It's also weird the connection created after the DNS response is limited to http/1.1, since the HTTPS record tells http/2 is available too :

1 crypto.cloudflare.com (alpn="http/1.1,h2" ipv4hint="162.159.137.85, 162.159.138.85" echConfig="0046FE0D00421F002000209DE32E4D7833DAEC13F2A2BB721AACA56B6CECEB3555C52E11F183DB012B6A470004000100010013636C6F7564666C6172652D65736E692E636F6D0000" ipv6hint="2606:4700:7::a29f:8955, 2606:4700:7::a29f:8a55" )

https://hg.mozilla.org/mozilla-central/rev/c58f85803035
https://hg.mozilla.org/mozilla-central/rev/b773dff5cb92
https://hg.mozilla.org/mozilla-central/rev/0180df85922f