Closed Bug 1500289 Opened 6 years ago Closed 25 days ago

Support using the OS Resolver for ECH

Categories

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

enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1852900

People

(Reporter: jan, Unassigned)

References

(Blocks 1 open bug)

Details

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

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

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

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.

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.

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.

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.

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?

Flags: needinfo?(djackson)

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.

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

Flags: needinfo?(djackson)

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.

@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).

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.

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/

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.

 >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

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?

Severity: normal → S3
Summary: Please allow regular ESNI (without DoH) → Support using the OS DoH Resolver for ECH
Depends on: 1718485
Duplicate of this bug: 1542754
Blocks: ech
No longer blocks: 1590863

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?

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.

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

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.

Summary: Support using the OS DoH Resolver for ECH → Support using the OS Resolver for ECH

I would also like this to happen.

Depends on: 1852752

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.

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.

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

Priority: P5 → P3
Whiteboard: [necko-triaged] → [necko-triaged][necko-priority-review]

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

Status: NEW → RESOLVED
Closed: 25 days ago
Duplicate of bug: 1874464
Resolution: --- → DUPLICATE
No longer depends on: 1718485
No longer depends on: 1852752
Duplicate of bug: 1852900
No longer duplicate of bug: 1874464
You need to log in before you can comment on or make changes to this bug.