1638053 - ESNI + webproxy not working: nsSocketTransport::ResolveHost()

Status: RESOLVED WONTFIX

(Core :: DOM: Networking, defect)

Description

[amritanshu]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36

Steps to reproduce:

I am trying to make ESNI work with a web-proxy, what I am observing is that although the tunnel is TLSv1.3 the SNI is still going in plain text. This is not a MITM-SSL proxy

Point FF to the proxy
access and test browser for ESNI https://www.cloudflare.com/ssl/encrypted-sni/

Actual results:

The connection was TLSv1.3 the SNI went in plaintext

Expected results:

In nsSocketTransport::ResolveHost() (where we also compute the ESNI keys), the problem is on Line number 1080 where esniHost.Append(SocketHost()); it ends up picking the ProxyAddress instead of the host see[0], ultimately leading to a lookup for _esni.127.0.0.1 or whatever is there in the proxy instead of _esni.some.encryptedsnihost.com in the DNS cache.

Looking up ESNI for the proxy is bad for multiple reasons, best case the ESNI keys are not found and the TLS tunnel is "degraded", but in the worst case, the proxy itself has an ESNI key present, where the TLS HELLO packet gets encrypted with the wrong key. Ideally the connection should have been encrypted.

Comment 1

[amritanshu]

Attachment: log.txt-main.2204.rar

Adding the logs for the failure scenario

Comment 2

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[amritanshu]

I have rephrased the bug here the original summary is like putting the Horse before the Cart, apologies for that.

Steps to reproduce:

1. ensure the DNS is pointing to CloudFlare DNS
2. enable esni bits on FF under ESNI and network.security are set to true in about: config
3. visit https://www.cloudflare.com/ssl/encrypted-sni/ and run Esni test
4. Esni Test Passes.
5. enable proxy settings in FF, in my case HTTP/https was manually set to talk to 127.0.0.1:3128
6. revisit https://www.cloudflare.com/ssl/encrypted-sni/ and run Esni test
   Actual result:
7. the test fails, the Cloudfare response says the SNI was sent in plaintext.
   Expected result:
   The test should pass.

Existing debugging/RCA:
In nsSocketTransport::ResolveHost() (where we also compute the ESNI keys), the problem is on Line number 1080 where esniHost.Append(SocketHost()); it ends up picking the ProxyAddress instead of the host see[0], ultimately leading to a lookup for _esni.127.0.0.1 or whatever is there in the proxy instead of _esni.some.encryptedsnihost.com in the DNS cache.

Looking up ESNI for the proxy is bad for multiple reasons, best case the ESNI keys are not found and the TLS tunnel is "degraded", but in the worst case, the proxy itself has an ESNI key present, where the TLS HELLO packet gets encrypted with the wrong key. Ideally, the connection should have been encrypted.

Comment 4

[Jeronimo Torti (Please send NI request to Brindusa Tot)]

Hi,
I don't have the technical knowledge to confirm this issue but I'll add product and component so the team can make some research on it. Hopefully, someone with a more deep understanding of this matter can help. Feel free to route this ticket to the corresponding team.

Comment 5

[Dragana Damjanovic [:dragana]]

The old ESNI spec has some problems with proxies. There is a new one and a new DNS query for it, HTTPSSVC. We will be working on an implementation in the near future. I will closed this bug as WONTFIXED

Comment 6

[amritanshu]

[:dragana] so the issue is meant to go away in a future release?

Comment 7

[Dragana Damjanovic [:dragana]]

(In reply to amritanshu from comment #6)

[:dragana] so the issue is meant to go away in a future release?

yes