1500289 - Support using the OS Resolver for ECH

Status: RESOLVED DUPLICATE of bug 1852900

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

Description

[Darkspirit]

Attachment: 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?

Comment 1

[Darkspirit]

Attachment: unbound.png

With our regular dns configuration it looks basically the same.

Comment 2

[Daniel Stenberg [:bagder]]

> 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!

Comment 3

[Darkspirit]

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.

Comment 4

[pleasedontspam]

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

Comment 5

[Darkspirit]

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.

Comment 6

[uBlock-user]

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.

Comment 7

[yonkou]

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

Comment 8

[u589248]

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.

Comment 9

[Tom Ritter [:tjr]]

(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

Comment 10

[Mark Straver]

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.

Comment 11

[alterstep]

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?

Comment 12

[val.zapod.vz]

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

Comment 13

[val.zapod.vz]

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!

Comment 14

[progandy]

(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

Comment 15

[alterstep]

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.

Comment 16

[nightkhaos]

If this blocks 1590863 should it not be escalated from P5 to P3 or even P2?

Regardless of where the draft goes, we're going to need to send an arbitrary query to and restricting that ability to DoH only is hamstring alternative network deployments like a DoT resolver.

Comment 17

[david_osipovv]

Great idea. Also was struggling with ESNI. I do have a Pi-hole+unbound in my local network, which is doing a good job. I do not want to trust only Cloudflare with Firefox DOH queries, so I have 2 options:

1. To trust Cloudflare with ALL DNS-over-HTTPS queries and turn on ESNI.
2. To use my Pi-hole + unbound without ESNI, but with huge privacy and security enhancements.

Comment 18

[Ferdinand Mütsch]

(In reply to david_osipovv from comment #17)

Great idea. Also was struggling with ESNI. I do have a Pi-hole+unbound in my local network, which is doing a good job. I do not want to trust only Cloudflare with Firefox DOH queries, so I have 2 options:

1. To trust Cloudflare with ALL DNS-over-HTTPS queries and turn on ESNI.
2. To use my Pi-hole + unbound without ESNI, but with huge privacy and security enhancements.

I am facing the exact same problem. Neither of both options are sufficient to me. I would really appreciate it, if Firefox could support ESNI without requiring to use the built-on DoH mechanism.

Comment 19

[yetanotheremail]

(In reply to Daniel Stenberg [:bagder] from comment #2)

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!

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 :-(

Comment 20

[progandy]

(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.

Comment 21

[Mark Straver]

I'm afraid "Me Too" signalling is all anyone can really do here because of how it's put in the "p5" pile while this is a task that only Mozilla engineers can really address. The same thing is true for anything that needs to happen in NSS.
This needs to either be re-prioritized (which might happen if enough people indicate in this bug that it's very much wanted) or assistance given how to approach this problem to offer patches.

Comment 22

[github]

The most common workaround is using https://dnscrypt.info's local DoH feature, but this is really overkill for local setups.

If a local DNS server/proxy is already trusted, ECH is totally fine and safe to use.

Comment 23

[rigydu]

Mozilla: No one's wants this obscure feature, so it's not a priority.
Also Mozilla: Signalling that you want this won't help. Your post will be flagged. Feel free to continue talking to the walls.

P5 exists for the illusion on open dialogue, without having to give any ground. Whilst I have the technical know-how to create a patch, there is simply no motivation no motivation to do so. It will not be accepted even if it will help others.

Comment 24

[Dragana Damjanovic [:dragana]]

Original decision was made because the plain DNS was not encrypted and host names are already leaked. Now OSs implement DoT and DoH and we will reconsider implemented this. I do not know about the time line yet.

Comment 25

[Thayne]

In addition to system DNS using DoT or DoH directly, it's also possible that DNS could be going over a VPN with a split tunnel.

Comment 26

[mcccs]

Hi,

I looked into fixing this. One question -- is the TXT/HTTPSSVC/SRV equivalent of GetAddrInfo already implemented? If so, I'm about to prepare a patch. Otherwise, this might need Linux/Mac/Windows specific code which I can't write.

Thanks.

Comment 27

[Hans-Christoph Steiner]

On Android, DnsResolver.rawQuery() will get whatever RRs you need, but it returns the raw DNS Answer which must then be parsed. And this is only on Android newer than API 29.

https://developer.android.com/reference/android/net/DnsResolver#rawQuery(android.net.Network,%20java.lang.String,%20int,%20int,%20int,%20java.util.concurrent.Executor,%20android.os.CancellationSignal,%20android.net.DnsResolver.Callback%3C?%20super%20byte[]%3E)

Comment 28

[Tom Ritter [:tjr]]

Dennis - what's the deal with ESNI / ECH? Is ECH bound by the same restriction for DoH? If so would a patch for ESNI be applicable easily to ECH also?

Comment 29

[Hans-Christoph Steiner]

IMHO encrypted DNS does not need to be a hard requirement for ECH per se. It could be a useful way to check for modern DNS capabilities, since ECH will need successful HTTPS/SVCB DNS queries to function.

Comment 30

[Dennis Jackson]

(In reply to Tom Ritter [:tjr] (ni? for response to CVE/sec-approval/advisories/etc) from comment #28)

Is ECH bound by the same restriction for DoH?

Yes, there have been only minor changes at the DNS record level between ESNI and ECH. In brief, the user's DNS queries reveal exactly which websites they are visiting over ECH and so protecting them is vital. In general, I don't think we can/should trust network provided values unless the user has explicitly opted in (e.g. through a pref).

If so would a patch for ESNI be applicable easily to ECH also?

The changes needed to support non-DoH resolvers would all happen outside of NSS and are independent of my work on the ECH implementation. NSS just needs to provided with the configuration string fetched from the DNS records and then handles the rest.

Comment 31

[Kevin Cox [@kevincox:matrix.org]]

the user's DNS queries reveal exactly which websites they are visiting over ECH and so protecting them is vital.

In the general sense of privacy I think DoH is vital. But I don't see how it is vital for this feature. My understanding is that ECH is no worse than the current state, even if the DNS request was being tracked. It seems to me like we may as well do ECH so that if the DNS query happens to be private (whether because of DoH or just because the resolver is trustworthy) then you have a fully private experience.

I fail to see the downside of just allowing this all the time, I agree that in most cases without DoH or similar it doesn't provide complete protection. But it is still an improvement in many cases.

Comment 32

[Dennis Jackson]

@Kevin: I want to clarify this isn't a case of 'just allowing this'. Widening the support in Firefox for ECH over additional DNS transports will require reworking the low level code and a considerable amount of testing to make sure we don't break connectivity for users with older DNS resolvers. For experts who are early adopters and would like to use ECH with their own local resolvers, this is currently possible with a moderate amount of additional effort (enabling a local DoH endpoint and setting it in Firefox).

Comment 33

[sjw]

DoH/DoT could also happen on the host or local network. This cannot be detected by Firefox. DoH is not enabled by default for most users.
Requiring DoH for ECH would prevent a large user base from using it, e.g. split DNS environments, adblock DNS or DNSSEC aware setups.

Comment 34

[val.zapod.vz]

I will also add that windows 11 supports DoH out of the box now (ipv6, ipv4, two different addresses for both) no problem. Also, some people may use unencrypted DNS over a different AS/ISP or do an ONION APNIC resolver (https://developers.cloudflare.com/1.1.1.1/other-ways-to-use-1.1.1.1/dns-over-tor) or local recursive resolver!!

That is this: https://dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion/

Comment 35

[Hans-Christoph Steiner]

I agree encrypting DNS is important, and requiring Firefox use its own DoH before enabling ECH seems like a good step towards a complete implementation. My fear is that this DNS change will become permanent. Avoiding the centralization of DNS is also important. I think that encrypting the SNI field (e.g. using ECH) while maintaining decentralized DNS is more important than encrypting the DNS. The SNI is plain text so its visible to all networks where the packet passes through. DNS is commonly hosted on the client's network and there is already local caching in place, so its less visible than the SNI field.

Comment 36

[val.zapod.vz]

 >My fear is that this DNS change will become permanent. 

Not important! What is important is that it is slow and loads only 2 or 3 seconds after browser is loaded, b) it is not implemented as kernel module and is not part of the kernel, so it is higher latency

Comment 37

[Thayne]

From my understanding Firefox would also want to query SVCB/HTTPS DNS records to optimize determining if HTTP/3 is supported, and probably to know if it should prefer https to http. Or will those features also be gated by having DoH enabled?

Comment 39

[sjw]

The original report was without DoH, not limited to a DoH resolver on the OS. DoH is not the only (secure) method to resolve domains. As outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1590746#c8, I'd not limit ECH to DoH. Can we please revert the summary change?

Comment 40

[github]

Yes, "support the OS resolver" would be a more accurate title.

ODoH, DoOH, DNSCrypt, Anonymized DNS, DoQ and future DNS-over-something methods are totally fine for ECH as well.

Comment 41

[Matt]

There's also no need for DNS-over-* for ECH - ECH can add substantial security value by allowing an outside-of-CA way to communicate the server's private key (ie the DANE security model), for which you need only a secure channel for DNS, not an encrypted one, DNSSEC via standard ol' UDP port 53 more than suffices. For privacy, too, you may trust the path to your resolver (eg if its on the host if Firefox is running in a VM, or if its on your local network) without trusting the full public-internet path from you to the server (eg not trusting your ISP, not trusting an ISP reseller, etc).

Comment 42

[Mark Straver]

I agree the current bug topic is not at all what the intent was here, which is to support an encrypted hello without enforcing DoH, or DNS-over-anything, for that matter. They should not be conflated or forcefully coalesced. Please revert to the original intent.

Comment 43

[asalawless5c]

I would also like this to happen.

Comment 44

[dohevypzmzbrhegnnk]

Note that using ECH only for DoH discloses to the server whether the user uses DoH or not, which is a minor new privacy leak, a new fingerprinting vector for distinguishing visitors.

Every MITM able to observe some hops in the connection also gets that same information even if they can't observe the DNS resolution itself.

Comment 45

[Atmospheric Ignition]

I would love to see this feature implemented in Firefox. I use DoH configured via a macOS configuration profile, and since I often use VPNs for both privacy and work purposes. I constantly have to constantly manually enable and disable secure DNS in Firefox, since I want to be able to leverage using ECH when I'm not using a VPN, and prevent DNS leaks when using a VPN. Even the privacy nightmare called Google Chrome currently supports ECH using the OS resolver, so it pains me a little to see this issue be given a P5, the lowest priority, essentially indicating this won't ever be implemented.

Comment 46

[Darkspirit]

I have found this:
https://github.com/rustls/rustls/pull/1718/files#diff-b394a2611c7b41b4e372276bdfe57e14ad9c3f8b1f85f40b77d358dd098c0c08R83-R97
let resolver = Resolver::new(ResolverConfig::google_https(), ResolverOpts::default()).unwrap();

fn lookup_ech(resolver: &Resolver, domain: &str) -> Vec<u8> {
    resolver
        .lookup(domain, RecordType::HTTPS)
        .expect("failed to lookup HTTPS record type")
        .record_iter()
        .find_map(|r| match r.data() {
            Some(RData::HTTPS(svcb)) => svcb
                .svc_params()
                .iter()
                .find_map(|sp| match sp {
                    (SvcParamKey::EchConfig, SvcParamValue::EchConfig(e)) => Some(e.clone().0),
                    _ => None,
                }),
            _ => None,
        })
        .expect("missing expected HTTPS SvcParam EchConfig record")
}

https://www.memorysafety.org/initiative/dns/
https://github.com/hickory-dns/hickory-dns/tree/main/crates/resolver

• resolver from system config:
  let resolver = Resolver::from_system_conf().unwrap();

  • Windows
  • Unix
  • But Android is not fully supported yet: https://github.com/hickory-dns/hickory-dns/issues/652#issuecomment-1782431288

• resolver from user-provided config:
  https://docs.rs/hickory-resolver/latest/hickory_resolver/struct.Resolver.html#method.new
  https://docs.rs/hickory-resolver/latest/hickory_resolver/config/struct.ResolverConfig.html#method.from_parts

  domain - domain of the entity querying results. If the Name being looked up is not an FQDN, then this is the first part appended to attempt a lookup. ndots in the ResolverOption does take precedence over this.
  search - additional search domains that are attempted if the Name is not found in domain, defaults to vec![]
  name_servers - set of name servers to use for lookups, defaults are Google: 8.8.8.8, 8.8.4.4 and 2001:4860:4860::8888, 2001:4860:4860::8844

  https://docs.rs/hickory-resolver/latest/hickory_resolver/config/struct.NameServerConfigGroup.html#method.from_ips_clear
  https://docs.rs/hickory-resolver/latest/hickory_resolver/config/struct.NameServerConfigGroup.html#method.from_ips_tls
  https://docs.rs/hickory-resolver/latest/hickory_resolver/config/struct.NameServerConfigGroup.html#method.from_ips_https
  https://docs.rs/hickory-resolver/latest/hickory_resolver/config/struct.NameServerConfigGroup.html#method.from_ips_quic
  https://docs.rs/hickory-resolver/latest/hickory_resolver/config/struct.NameServerConfigGroup.html#method.from_ips_h3
  https://docs.rs/hickory-resolver/latest/hickory_resolver/config/struct.NameServerConfigGroup.html#method.merge

  let ips: &[IpAddr] = &[
      IpAddr::V4(Ipv4Addr::new(8, 8, 8, 8)),
      IpAddr::V4(Ipv4Addr::new(8, 8, 4, 4)),
      IpAddr::V6(Ipv6Addr::new(0x2001, 0x4860, 0x4860, 0, 0, 0, 0, 0x8888)),
      IpAddr::V6(Ipv6Addr::new(0x2001, 0x4860, 0x4860, 0, 0, 0, 0, 0x8844)),
  ];
  let name_servers = NameServerConfigGroup::from_ips_clear(ips, 53, true);
  // name_servers.merge(name_servers_2);
  // name_servers.merge(name_servers_3);
  let config = ResolverConfig::from_parts(None, vec![], name_servers);
  let resolver = Resolver::new(config, ResolverOpts::default()).unwrap();
  

Comment 47

[Valentin Gosu [:valentin] (he/him)]

The implementation is already done and behind a pref. bug 1874464 will turn it on.