Open Bug 1500289 Opened 2 years ago Updated 1 day ago

Please allow regular ESNI (without DoH)

Categories

(Core :: Networking: DNS, enhancement, P5)

enhancement

Tracking

()

People

(Reporter: darkspirit, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: feature, nightly-community, Whiteboard: [necko-triaged])

Attachments

(2 files)

Attached image screenshot.png
Debian Testing

STR:

servo.org is hosted on Cloudflare and has an ESNI record:
$ dig TXT _esni.servo.org +short
"/wFBbh+pACQAHQAgWOxePWsGi6pv7H58y0Qutk223JzeuZLmCra5UQFsbU4AAhMBAQQAAAAAW8UqAAAAAABbzRMAAAA="

But it doesn't seem to work with Nightly:
$ mozregression --launch 2018-10-18 --pref network.security.esni.enabled:true -a https://servo.org/cdn-cgi/trace
> fl=75f21
> h=servo.org
> ip=2003:[censored]
> ts=1539908194.146
> visit_scheme=https
> uag=Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0
> colo=HAM
> spdy=h2
> http=h2
> loc=DE
> tls=TLSv1.3
> sni=plaintext

Screenshot = https://www.cloudflare.com/ssl/encrypted-sni/

Actual:
> sni=plaintext

Expected:
> sni=encrypted
https://tools.ietf.org/html/draft-ietf-tls-esni-01
It's so cool that Firefox wants to support this.
DoH is not part of the ESNI standard, just mentioned as one way to ensure authenticity and privacy, so I would expect that ESNI just works if it's enabled. Could this be an OS-related problem?
Attached image unbound.png
With our regular dns configuration it looks basically the same.
> DoH is not part of the ESNI standard

No, but DoH is required by Firefox to get ESNI going so please first make sure you have that enabled!
Thank you for supporting ESNI at all! :) But sorry for the misunderstanding.

I have two concerns, while not knowing your general plans:
* ESNI shouldn't be artifically restricted to DoH.
  I would assume that Firefox has a mature DNS library or would switch to c-ares or will oxidize[1] to TRust-DNS[2] sooner.
  Adding this to the appropriate meta bug for later would be fine, but awesome if it would be just a small change.

  [1] https://wiki.mozilla.org/Oxidation
  [2] https://github.com/bluejekyll/trust-dns

  * ESNI should be enabled by default at a later stage:
    If someome is not part of an organization and doesn't have a secure DNS via VPN, DoH or DoT,
    ESNI would still protect TLS connections leaving the ISP
    to prevent combination of intercepted Source IP + SNI with other tracking intel.
    If problems are expected with corporate environments, it could be disabled by default for ESR.
OS: Linux → All
Hardware: x86_64 → All
Summary: Regular ESNI doesn't seem to work → Please allow regular ESNI (without DoH)
Priority: -- → P5
Whiteboard: [necko-triaged]
I have tested with Stubby and Dnscrypt-Proxy with DOT and DOH.
It seems to fail the ESNI test. May I know why?

Stubby: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
Dnscrypt-Proxy: https://github.com/jedisct1/dnscrypt-proxy
https://twitter.com/bagder/status/1052994271459123201
> "I'm wondering why DoH is a requirement to enable ESNI?"
> For technical reasons. That's the only code for "raw" DNS packet handling we have in Firefox.

They want to get a foot in the door for ESNI. This seems to be an absolute MVP as
* there's currently no support for ESNI using the system's resolver (this bug),
* enforcing long-term privacy breaks ESNI (bug 1500526), and
* you can't even enforce SNI privacy for testing purposes.
So I assume we just have to be patient.

I use dnscrypt-proxy found at https://github.com/jedisct1/dnscrypt-proxy which already has DoH/ESNI implemented, so Firefox should be able to detect that and be aware of it, that way I don't have configure DoH in Firefox to ensure ESNI working.

same thing here, i use stubby with my system resolver, encrypted DNS works fine, but the ESNI feature in firefox seems to require the firefox built-in resolver; that makes no sense to me, aren't DNS and SNI two completely seperate things?
https://i.postimg.cc/tTTrbZyq/Jul11-110531.png

I was wondering why this is at P5 priority. Is this definitely something that you "basically never want" (as per Moz Priority System)? This seems like a very sensible feature.

(In reply to Vishnu from comment #8)

I was wondering why this is at P5 priority. Is this definitely something that you "basically never want" (as per Moz Priority System)? This seems like a very sensible feature.

That page is actually how the Bugzilla projects assigned priorities for the development of Bugzilla.

https://mozilla.github.io/bug-handling/triage-bugzilla is what the priority means for Firefox. So this one is P5 - Will not fix, but will accept a patch

The general meaning behind the priorities is the same, though. P5 is "We'll never work on this but -may- accept a patch if someone submits it" which basically never happens.

It does seem like a very sensible feature to have. Requiring DoH for ESNI to work is not very sensible since they are separate mechanisms and have no strict dependencies between them (aside from the Mozilla implementation not supporting what's needed without DoH enabled). If we actually want this to become more widely adopted, it shouldn't be locked behind a different feature that has privacy drawbacks and might not be enabled because of that.

Encrypted DNS can be installed for the entire system and even for the entire network (dnscrypt-proxy, simplednscrypt, pi-hole...)
-> Firefox should not require ESNI to depend on its internal DNS resolver.
If the DNS is already encrypted, there are no technical reasons not to enable ESNI. The only reasons I can see are political.
Can we at least expect a preference flag?

What does it mean patch welcome? I am perfectly sure that the patch is changing one or 2 line in code!
I will also copy my issue https://bugzilla.mozilla.org/show_bug.cgi?id=1542754

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

Steps to reproduce:

If you put 1dot1dot1dot1.cloudflare-dns.com in Private DNS in Android 9, DNS over TLS will be activated and working. But your Trusted Recursive Resolver doesn't consider it, it still should be activated to access network.security.esni.enabled set to true.

Actual results:

Trusted Recursive Resolver should be activated though the user may already have DoH or DoT installed. Also I don't understand why DNS should be encrypted. All that happens in encryption of SNI in DNS part is asking public key from TXT of _esni. subdomain of the domain you accessing; I understand the risk of DPI finding out _esni DNS query, but on the other hand, DPI will not intervenue with TLS 1.3 eSNI connection itself, it will be very helpfull in countries, which has such DPI regulation; besides that DNS queries are cached, so it means that even if DPI will block access the first time, the second time it should work.

Expected results:

network.security.esni.enabled should not be connected with TRR in any way, after that I think we should rewrite its defaults to true. Look into it; make sure that if any problems to connection happen, it would go down to non encrypted SNI. But true should be the defaults.

Besides that I think we should help Google to implement it. After all I think the idea of eSNI has the same level of revolution as ephemeral keys of perfect forward secrecy in https. After that DNSSEC keys can be used as certificates insteed of CA certificates. And I am not talking about only IP blocks possible after eSNI will become popular. Post DPI era is coming!

Look into https://bugs.chromium.org/p/chromium/issues/detail?id=908132

Also tell me please about my comment "look there, I asked chromium devs about which DNS query (ESNI or TXT) they are going to use. And they will use ESNI. https://bugs.chromium.org/p/boringssl/issues/detail?id=275#c_ts1561592153

Are you in contact with cloudflare? What are they going to do?"
This is unacceptable!

(In reply to val.zapod.vz from comment #12)

What does it mean patch welcome? I am perfectly sure that the patch is changing one or 2 line in code!

It is a bit more, Firefox first has to implement a DNS resolver for non-DoH queries since it only uses getaddrinfo to resolve IP addresses. Additional DNS queries can be implemented with res_nquery from libresolv (included in glibc >= 2.9) on linux and DnsQuery_A on windows.

I have taken a look at the code and it seems like in nsHostResolver::ResolveHost you have to allow for queue priority adjustments for non-A/AAAA records, in nsHostResolver::NameLookup you have to allow native non-address lookups, nsHostResolver::NativeLookup has to be adjusted, and in nsHostResolver::ThreadFunc you have to call res_nquery for non-A/AAAA and then parse the result with functions from /include/arpa/nameser.h. The functions in this header are part of the libresolv API, but have no documentation. In a second codepath use DnsQuery_A. You might also have to move around members of nsHostRecord, TypeHostRecord, and AddrHostRecord.

I have no idea about android, maybe it is possible with DnsResolver::rawQuery or does it support libresolv as well? rawQuery also requires implementing functions to create dns queries as binary data and parse the response.

I have not enough time to compile and test it on my slow computer, so I don't think I will create a patch.

http://man7.org/linux/man-pages/man3/resolver.3.html
https://docs.microsoft.com/en-us/windows/win32/api/windns/nf-windns-dnsquery_a
https://developer.android.com/reference/android/net/DnsResolver.html

Progandy: thank you for looking at it. To clarify this is because it has to send other query types than A and AAAA.

But this is already implemented for DoH. The code to create and parse DNS packets is already there. Instead of sending these packets using HTTP it would be sending it over TCP or UDP to the system resolver.

Blocks: esni

(In reply to yetanotheremail from comment #19)

I'm using 79.0 (64-bit). I use dns through my pi-hole which does secure dns. I don't want firefox to use its own, I just want it to do what the dhcp server in my router says: use the pi-hole dns.

But I do want ESNI. But firefox won't let me because of this :-(

"Me too" signaling will not help much.

As a stop-gap solution you can run your own DoH-server on the pi-hole with doh-proxy. You'll have to manually configure each Firefox installation and If you use a self-signed certificate then you have to tell Firefox to trust it. (Open the DoH-URL https://YOURIP:YOURPORT/dns-query in the browser and accept the certificate before changing the DoH settings)
One option is to run dns-proxy on a second IP on the pi-hole. Otherwise choose an unused port or set up a reverse-proxy that delegates traffic between the pi-hole backend and DoH. For more support you should probably ask the pi-hole community.

You need to log in before you can comment on or make changes to this bug.