On Fri, 11 Apr 2014, Dan Williams wrote:
That's great. Thank you so much for sharing this information. I'll add it to the wiki page.
About the wifi hotspots breakage, I'm still not in the clear. IIUC how they work is, all client traffic is blocked/redirected to a designated server till the time user authenticates/makes payment/accepts conditions etc. This blockage/redirection is probably done on the the gateway or some such entry/exit point, no?
They almost always run DNS interceptors, so that the DHCP server on the captive side always returns the portal's login page for any request, even "www.google.com" or "www.fedoraproject.org" will redirect you to the login page. Obviously that DNS reply will not be authenticated or secure in any way, because it clearly cannot be a trusted reply from google.com. Thus they will break any kind of DNSSEC or any other kind of authentication that the local caching DNS server might do.
There are two captive technologies that need to be checked for. One is port 80/443 interception and one is DNS interception. dnssec-triggerd offers those but its integration with NM is poor because it was written as a stand aline daemon+gnone applet.
On top of the captive portals, the solution needs to deal with VPN situations and split-view DNS. Unbound handles this with libreswan, vpnc and openvpn already. This also involves flushing the cache when the VPN connection goes up/down. unbound supports all of this via runtime unbound-control daemon reconfiguration and also supports shipped exceptions via /etc/unbound/*.d/ directories.
I am not aware of dnsmasq offering these features at all. dnsmasq also only very recently got beta suppor for dnssec, so I am uncomfortable with using dnsmasq for these tasks.
I think the big issue for me is the use of "trusted" in the proposal. What does that actually mean? Who is doing the trusting? Does it mean that Firefox can "trust" the local caching DNS server, and if so, why would that server be any more "trustworthy" than the upstream nameserver delivered to you by DHCP? If that local nameserver *is* somehow more trustworthy, what specifically does it do to deserve that trust? If it does do something, does that something break hotspot or portal detection and login?
The DNSSEC trust comes from a shipped root key that's local to your machine, augmented by installed trust anchoes (eg in /etc/unbound.d/keys.d/). This means all the validation happens on the host and cannot be mangled in transit by an attacker. The alternative is to request a non-local DNS server with DNSSEC support and looking at the answer's AD bit. But this bit is not cryptographically protected, so it assumes a trust in the network.
What would be the most awesome solution, is if NM on finding a new network connection, can bring up a secure container with resolv.conf from the DHCP server, do the captive portal tests, allows the user to login in a throw away browser context, and once accepted on the network, and the mangling has stopped, to release the actual network to the rest of the OS and destroy the used container.
Paul