On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote: >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote: >> > decision needs to then be made by the system. I believe that's been >> > mostly due to lack of time for the various parties to sit down and >> > plan and then program this further. >> >> We should try to make that happen. > > 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. > >> > >I see that there's a "hotspot sign on" option if you right click on the >> > >icon. How does this work with Network Manager and GNOME's captive >> > >portal detection? >> > I have never seen those work except for when the backend was down and >> > I got a stream of false positives. But possibly that is because I've used >> > dnssec-trigger for years now and it might win the captive portal >> > detection race. There are some bugs once in a while but overal it works >> > pretty reliably. >> >> I think that's probably it — the race. The hotspot signon thing works >> for me at coffeeshops. Or it did before I enabled this feature. We'll >> see now! > > 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. I think that part of the problem is that there are too many implementations of captive portal detection and too many half-thought-out implementations of what do do if a captive portal is detected. I think that, on a well-functioning system, if I connect to a wireless network, something should detect if I'm behind a captive portal. If so, I should get a stateless browser that clearly indicates that it's a captive portal browser, probably lives in a sandbox, and sees the raw view of the network (no local DNSSEC validation). We have network namespaces -- the browser part is doable even in a scenario where we wouldn't want to expose the incorrect view of DNS or some other aspect of the network to normal applications. (Heck, on a configuration where we want to use a VPN over untrusted wireless, we could avoid exposing the untrusted wireless network to applications other than captive portal login at all.) Please note that the current GNOME captive portal mechanism is blatantly insecure, and I've already filed a bug report with no resolution. I'm not disclosing a subtle 0-day here -- the insecurity is fairly obvious. I'll probably post to oss-security soon, but that's a somewhat separate topic. Once we determine that there's no captive portal or that we've logged in to it, we should validate DNSSEC and otherwise behave sensibly. If the network is screwed up enough that normal DNSSEC can't get through the DHCP-provided resolver (which happens -- I've seen ISPs that tamper with DNS results for www.google.com), then we should tunnel around it. IIRC dnssec-triggerd already supports this. > > 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. There is nothing > wrong with having DNSSEC enabled and part of the portal detection > scheme, but the UI handling portals is clearly a desktop-specific > decision. This hasn't worked so well in the past. Back when NM provided its own UI, that UI tended to work. These days I frequently notice the gnome-shell UI for networking, bluetooth, etc missing features that are supported by the backend or just straight-up not working. > So whatever we need to do in NM to enable the workflow that > 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 Updates what information to what? resolv.conf should be more or less invariant. > 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? I smell a turf war, sadly. I don't think that "local unbound using dnssec-triggerd isn't NM" should be a show-stopper. I'd like the see the result work correctly, and, honestly, if gnome-shell isn't part of the solution, then that's probably a good thing. Clearly it should be integrated enough with NM to be aware of connectivity changes, and it should probably integrate more deeply than that, but if the end solution bypasses NM's captive portal detection entirely, that doesn't seem like an a priori problem to me. Merging all of dnssec-triggerd into NM might be a decent solution. Keep in mind that a good DNSSEC solution is fundamentally tied to captive portal login. There are probably many captive portals behind which it's impossible to get DNSSEC before login but where, once logged in, tunneled or even normal DNSSEC is possible. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
