On Fri, 12 Jun 2015, Dan Williams wrote:
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.
In hotspot mode (dnssec-trigger's version of hotspot mode)
/etc/resolv.conf contains the DHCP supplied DNS servers. Those are used
to determine both the "DNS cleanliness" state, and is also used to fetch
the fedoraproject hot spot detection page. The unbound DNS server, while
running, is not used at all for anything, as resolv.conf does not point
to it. Unfortunately, because this is not isolated to dnssec-triggerd,
all applications doing DNS during this time get crap/dangerous DNS
resolves, leading to add the bad certificate warning popups. And why I
was hoping to isolate that with either a network namespace, or other
solution that prevents us from requiring to affect the whole system
by changing resolv.conf.
If selecting "cache only", then resolv.conf points to 127.0.0.1 and
unbound is configured with a "DNS forwarder" for everything set to
127.0.0.127 so no DNS lookups ever leave the host.
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.
Ahh thanks.
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"?
Sorry I meant "If no http redirect, and DNS is broken, then it tries to
work around by ...". That is, when there is an http redirect, there is
no point doing anything about DNS because after authenticating to the
hotspot, DNS might turn out to be either fine or broken for other
reasons.
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.
That would be awesome!
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
True. In fact with unbound it is pretty trivial to do. The equivalent
unbound python code for that would be:
import unbound
ctx = unbound.ub_ctx()
ctx.resolvconf("/this/networks/respresentation/of/resolv.conf")
any resolve calls made will use the non-system resolv.conf's nameserver
addresses.
So the hotspot check could be:
ctx = unbound.ub_ctx()
ctx.add_ta_file(rootanchor) # DNSSEC root key
ctx.resolvconf("/this/networks/respresentation/of/resolv.conf")
status, result = ctx.resolve("fedoraproject.org", unbound.RR_TYPE_A)
if not result.havedata or not result.secure:
# we're captive because fedoraproject.org is DNSSEC signed and
# we got an error (forged) response
# Redo query with a non-DNSSEC cache to get forged A record to
# authenticate to the hotspot
insecurectx = unbound.ub_ctx()
insecurectx.resolvconf("/this/networks/respresentation/of/resolv.conf")
status, result = insecurectx.resolve("fedoraproject.org", unbound.RR_TYPE_A)
if result.havedata:
addr = result.data.address_list[0]
# give addr to the captive portal logon HTTP engine
insecurectx.ub_close()
else:
if result.havedata:
# check for HTTP interception - we might still be captive
addr = result.data.address_list[0]
# give addr to the captive portal logon HTTP engine
ctx.ub_close()
Things are a little tricker because the hotspot likely stupidly uses
even more DNS calls to build up the logon page, so whatever the http
rendering agent is (eg xdg-open or firefox or whatever) needs to keep
using this unbound cache and not fall back to the system default one.
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?
If HTTP is no longer redirected (dnssec-trigger keeps probing while you
pull your credit card out), it assumes you have successfully authenticated
to the hotspot. It re-tests the supplied DNS servers. If these are still
determined to be too broken for using DNSSEC (eg too old bind,
dnsmasq) it tries to (silently) become a full itterative nameservers,
eg it will not use any forwards and do all the DNS work itself. If this
also fails, for example because the network blocks port 53 to all but
its own DNS servers, dnssec-trigger tries the other modes of DNS over
TCP/SSL. If any of this works the user isn't even consulted. Only when
all of this fails do we need to contact the user and ask them to go
"insecure" or "cache only"
Paul
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
