47 bytes, text/x-phabricator-request
|Details | Review|
47 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180402220122 Steps to reproduce: Just like there is a domain exclusion list for proxies (network.proxy.no_proxies_on), it would be nice to have an exclusion list for TRR. The reason is the following: privacy concious people will set network.trr.mode=3 because otherwise TRR fails silently and falls back to native, so an attacker could block google/cloudflare servers to force users to fall back to less secure DNS without them noticing. But in mode 3, there's no way to access either a company's internal services that are based on local domain names, or avahi/bonjour/whaterver .local addresses from services autodiscovery.
Severity: normal → enhancement
Component: Untriaged → Networking: DNS
Product: Firefox → Core
This is also a problem with network.trr.mode=2, where the company's public and internal DNS return different addresses for the same service (in my case the public site redirects to a gateway).
In my opinion all of the connection-specific dns suffix's and all of the system dns suffixes have to be excluded automatically. That should fix this issue in more than 99% of all cases.
@Mario, so all an attacker would have to do to log/manipulate DNS traffic is to push a search domain via DHCP? That's a too easy attack vector...
We are talking about company environment. Our DHCP/AD servers pushes some dns suffixes that have to be resolved by our local dns in any case. And no request must be sent out to the TRR due to security reasons. So which way would you prefer? Extra gpo's are not practicable.
Here is a part of my trr log. I set network.trr.mode==1 at the moment. The browsing to local domains works (zammad.foobar.eu has a rfc 1918 ip), but the query are also sent to the trr. I'd call this a security disaster. 2018-08-10 10:42:18,086: INFO: [HTTPS] Received: ID 0 Question google.com. IN NS Peer ('127.0.0.1', 48196) 2018-08-10 10:42:18,087: INFO: [DNS] Send: ID 55072 google.com. IN NS 2018-08-10 10:42:18,087: DEBUG: Waiting for DNS response 2018-08-10 10:42:18,304: INFO: [DNS] Received: ID 18901 www.google.com. IN A 2018-08-10 10:42:18,898: INFO: [DNS] Received: ID 55072 google.com. IN NS 2018-08-10 10:42:18,898: INFO: [HTTPS] Send: ID 0 Question google.com. IN NS Peer ('127.0.0.1', 48196) 2018-08-10 10:42:29,169: INFO: [HTTPS] Received: ID 0 Question zammad.foobar.eu. IN A Peer ('127.0.0.1', 48198) 2018-08-10 10:42:29,170: INFO: [DNS] Send: ID 41146 zammad.foobar.eu. IN A 2018-08-10 10:42:29,170: DEBUG: Waiting for DNS response 2018-08-10 10:42:29,171: INFO: [DNS] Received: ID 41146 zammad.foobar.eu. IN A 2018-08-10 10:42:29,172: INFO: [HTTPS] Send: ID 0 Question zammad.foobar.eu. IN A Peer ('127.0.0.1', 48198) 2018-08-10 10:42:29,173: INFO: [HTTPS] Received: ID 0 Question zammad.foobar.eu. IN AAAA Peer ('127.0.0.1', 48200) 2018-08-10 10:42:29,174: INFO: [DNS] Send: ID 48841 zammad.foobar.eu. IN AAAA 2018-08-10 10:42:29,174: DEBUG: Waiting for DNS response 2018-08-10 10:42:29,644: INFO: [DNS] Received: ID 48841 zammad.foobar.eu. IN AAAA 2018-08-10 10:42:29,644: INFO: [HTTPS] Send: ID 0 Question zammad.foobar.eu. IN AAAA Peer ('127.0.0.1', 48200)
"We are talking about company environment." and how do you differentiate between a "safe" environment and another one? How is Firefox supposed to know the difference between your "safe" corportate network (as if DHCP spoofing wasn't easy) and the coffee shop around the corner? I understand the requirement not to send your "private" hostnames to TRR, but the only safe way of achieving this is by a user-controlled preference or admin-controlled GPO. You *cannot* rely on DHCP for providing safe or accurate information. If your company is worried about TRR today, you can disable TRR with a GPO. If you company doesn't do GPOs, and still allows users to use whichever browser, then your company is not really worried about security.
Well, I've liked the FireFox for many years and I like the idea of doh or dot. But I see the requirements in our local network and in other companies I know. If an administrator has the choice between an IE that just works and a FireFox that needs GPO's, how will he decide? And don't forget that there are also networks where guests log in to access local websites (demo pages, training pages). This must also be possible. It may be an idea to define a switch like network.trr.trustLocalSuffixes with default true. Something you have to trust, and if a DHCP/AD in a company has been compromised, then the browser is the user's least of the problems.
> If an administrator has the choice between an IE that just works and a FireFox that needs GPO's, how will he decide? Firefox ESR "just works" since it doesn't contain DoH and is the recommended version for deployment in enterprises. I cannot speak for Mozilla, but I would be very surprised if this ever were backported to ESR 60 (except for the Tor Browser), lest being enabled there. > And no request must be sent out to the TRR due to security reasons. FYI, if you're business' security relies on the obscurity of internal domain names you already have to centrally disable search suggestions in any other browser, since those already leak any/most address bar input (Firefox otoh filters out what looks like URLs, though it may also leak domain fragments (single words)).
Regarding this issue I have the problem that we use internal dns overides for certain internet facing on-site hosted services. So webservice.example.com resolves to xx.xx.xx.xx internally and yy.yy.yy.yy externally. This is a functional requirement in the network for onsite hosted services. The devices on the network are not controlled by the administrators i.e. random user mobile devices.
Sorry if this is not the correct issue to add to, but there are two use cases where I am unable to use TRR in Firefox: 1. mdns. I have IoT devices that use hostname.local. I can access them fine when TRR is disabled, but when using network.trr.mode=3 I get "Server not found. Hmm. We’re having trouble finding that site.". 2. When managing my home router. It has a DNS name that resolves to 192.168.1.1. When TRR is enabled, I get the same error message as in case 1. For now, these problems have led me to use network.trr.mode=4
(In reply to Mikael Falkvidd from comment #10) > Sorry if this is not the correct issue to add to, but there are two use > cases where I am unable to use TRR in Firefox: > > 1. mdns. I have IoT devices that use hostname.local. I can access them fine > when TRR is disabled, but when using network.trr.mode=3 I get "Server not For both cases, you should be using mode=2 - which is TRR but falls back to regular DNS when TRR fails. mode=3 is strict, and does not fail back to DNS at all. https://gist.github.com/bagder/5e29101079e9ac78920ba2fc718aceec
Assignee: nobody → valentin.gosu
Priority: P3 → P2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/da9099238d4f Add way to clear DNS cache r=dragana https://hg.mozilla.org/integration/autoland/rev/d24302372a67 Add pref for list of domains excluded from TRR r=dragana
You need to log in before you can comment on or make changes to this bug.