On Fri, 2015-06-12 at 00:48 -0400, Paul Wouters wrote: > On Thu, 11 Jun 2015, Dan Williams wrote: > > > Unfortunately the Proposal doesn't say anything about how this will > > actually work, which is something NetworkManager needs to know. It also > > fails to address the failure cases where your local DNS doesn't support > > DNSSEC or is otherwise broken here out of no fault of your own. > > dnssec-trigger prompts the user with a choice of "allow insecure DNS" or > "cache only mode". The latter means "no new DNS and use what's already > in the cache only". Yeah, and the interaction story here has been controversial for a long time. The GNOME team certainly has ideas about how it should work, which are partly shown by the current hotspot/portal implementation in GNOME Shell. I'll let them discuss these ideas since NM is not involved in the higher-level UI story here, just the mechanics of providing "might this be a portal" to any NM client, GNOME Shell included. > > So, if you're behind a portal then unbound could potentially fail all > > DNS lookups. That means that NetworkManager's connectivity detection, > > which relies on retrieving a URL from a known website, will fail because > > the DNS lookup for it was blocked by unbound. Thus GNOME Shell portal > > detection will also fail. That kinda sucks. > > That is why HTTP redirection and DNS failure have to be detected by > whatever is the "hot spot detector". Both items weigh in on triggering > a hotspot logon window. Agreed. But how does the DNS failure actually get relayed to the thing doing the HTTP request, when unbound + DNSSEC is involved? That's one point I'm very unclear on. > > While I'm sure the dnssec-trigger panel applet works great for some > > people, I think the GNOME team would rather have the portal > > functionality in the existing GNOME Shell indicator. > > Everyone is in agreement here I believe. No one particularly likes the > dnssec-trigger ui. It was written as an desktop agnostic tool - for > instance it works on Windows and OSX. I'd love to see this better > integrated into gnome. > > > desktops need is what we'll end up doing... Ideally the process goes > > like this when unbound/dnssec-trigger are installed: > > > > 1. NM connects to a new network > > 2. NM updates DNS information > > I don't know what 2) means. If it means rewriting /etc/resolv.conf or > the unbound forwarder configuration, we have already lost if the DNS > was malicious (and/or a hotspot DNS) It means whatever "dns" action was set in NM, either writing resolv.conf, not touching anything (dns=none), sending split DNS to unbound (dns=unbound), or to dnsmasq (dns=dnsmasq), etc. In this case I'll presume dns=unbound. > > 3. NM waits for some signal from unbound/dnssec-trigger about the > > trustability of the DNS server > > 3a. if the DNS server is trusted, NM continues with its connectivity > > check > > 3b. if the DNS server is not trusted or DNSSEC is broken, then ??? How > > do we distinguish between "portal" and simply that your local DNS > > doesn't support DNSSEC or is otherwise broken, if we cannot resolve the > > address of the connectivity server? > > dnssec-trigger currently detects the difference by also checking for an > http hotspot redirect using http://fedoraproject.org/static/hotspot.txt > If no http redirect, then DNS is broken and it tries to work around it > by becoming a full iterative resolver or doing DNS over TCP or DNS over > TLS. and if it all fails, presents the "insecure or cache only" dialog. NM also checks for redirection. Though, what do you mean by "if no HTTP redirect, then DNS is broken"? Do you mean to prefix that with "If the correct response is not recevied..."? > But, if I could have my "ideal scenario", things would be a little > different: > > 1) NM detects a new nework, but doesn't tell the applications that there > is network connectivity yet. So firefox won't throw HTTPS warnings > and pidgin/IM won't throw https warnings. Because as far as they know > the network is still down. Agreed. Right now we have "connectivity" states, but they are all determined after the interface is signaled as "connected". We can do some work here to indicate connectivity status on this interface before indicating to applications that the interface is fully connected. > 2) NM/dnssec-trigger does the HTTP and DNS probing and prompting using > a dedicated container and any DNS requests in that container are > thrown away with the container once hotspot has been authenticated. > This would allow us to never have resolv.conf on the host be > different from 127.0.0.1. (currently, it needs to put in the hotspot > DNS servers for the hotspot logon, exposing other applications to > fake DNS) I'm not sure a container really needs to be involved as long as the DNS resolution can be done without hitting resolv.conf. That's not hugely hard to do I think as long as we can manually resolve the connectivity URI address without telling applications about the new DNS servers. Once we've determined that indeed we are on a hotspot, then we need to indicate that to the UI such that it can show the user a logon window with the hotspot's login page, or a username/password dialog (if WISPR or Hotspot 2.0 is involved) that uses private DNS servers too. At this point we're still untrusted. Then once the hotspot login is completed, we must re-do the connectivity check to ensure that we do indeed have access to the full internet. If we do, then we can finally signal "connected". If it fails again, then we either show the hotspot login window again, or somehow indicate that hotspot login failed. Note that none of this mentions DNS to the user at all yet... so what happens if the hotspot login succeeds, we get connectivity to the internet, but the hotspot DNS doesn't support DNSSEC correctly? Dan > 3) dnssec-trigger updates the unbound DNS configurtion and tells NM to > proceed. NM tells the applications there is new network connectivity. > > Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
