Re: F23 System Wide Change: Default Local DNS Resolver
- Original Message - On 18.6.2015 13:14, Bastien Nocera wrote: - Original Message - On 12.06.2015 19:00, Matthew Miller wrote: On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I plan to contact the GNOME folks about how they would be willing to better integrate the panel (most probably in a different form) into GNOME. I don't think we want to integrate one more panel applet. The information about the DNS security should be passed on from NetworkManager. Once that's figured out, we can discuss how to show that information. The code needs to integrate with various NetworkManager features, such as The code already integrates with VPNs. VPNs and connectivity checking. Adding any UI for network information provided via a side-channel would be premature. Could you elaborate how/why is the source of information tied to the UI? I suspect that networkd and others might not be very happy if the NetworkManager has to be available just to pass the information from whatever tool doing the actual job to the UI. networkd isn't supported as a backend for WorkStation (no gnome-shell, or gnome-control-center integration). And systemd doesn't like its internal services depending on third-party services. So you'd most likely have to talk directly to your DNSSEC service to get the information. Could you please explain how can we do that in environments without NetworkManager? Front-ends would talk directly to your service. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Am 18.06.2015 um 15:29 schrieb Bastien Nocera: I would love to see more will for cooperation from GNOME people, so we can converge to the working and well integrated solution. Vague claims that something is missing or something needs to be done, without clear reasoning is not helping anyone. It's a network feature, it needs to be integrated in NetworkManager for WorkStation to be able to configure it, and get status from it not all workstations are using NetworkManager and/or GNOME signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
- Original Message - On 18.06.2015 13:14, Bastien Nocera wrote: - Original Message - On 12.06.2015 19:00, Matthew Miller wrote: On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I plan to contact the GNOME folks about how they would be willing to better integrate the panel (most probably in a different form) into GNOME. I don't think we want to integrate one more panel applet. The information about the DNS security should be passed on from NetworkManager. Once that's figured out, we can discuss how to show that information. I think you should discuss with us the approach before saying that you don't want to integrate with dnssec-trigger. We wouldn't want to integrate with another network handler. We don't see any reason why the information should be passed back to NM. The information can be passed or gathered from dnssec-trigger itself. We don't want to lock ourselves only to NetworkManager, since there are also other network configuration managers. That's fine. But you'll need to do the integration in NM, so that gnome-shell, gnome-control-center and others NM front-ends can get the feature without needing to talk directly to dnssec-trigger in addition to talking to NetworkManager. You don't need to lock yourselves into NetworkManager, but front-ends already talking to NetworkManager should be getting the information through it, not through another service and arbitrate themselves. The code needs to integrate with various NetworkManager features, such as VPNs and connectivity checking. Adding any UI for network information provided via a side-channel would be premature. VPNs... done like 2 years ago. From what we discussed the connectivity checking is not really perfect in NM, since it assumes that DHCP provided resolvers are in resolv.conf because NM obviously uses system's stub resolver. If there are any valid integration pieces, please be specific. I don't want, in the Network panel, to be talking to 2 pieces of software that I'll need to aggregate myself to get a complete picture. I can imagine that gnome-shell developers will have a similar request. I would love to see more will for cooperation from GNOME people, so we can converge to the working and well integrated solution. Vague claims that something is missing or something needs to be done, without clear reasoning is not helping anyone. It's a network feature, it needs to be integrated in NetworkManager for WorkStation to be able to configure it, and get status from it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 18.6.2015 13:14, Bastien Nocera wrote: - Original Message - On 12.06.2015 19:00, Matthew Miller wrote: On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I plan to contact the GNOME folks about how they would be willing to better integrate the panel (most probably in a different form) into GNOME. I don't think we want to integrate one more panel applet. The information about the DNS security should be passed on from NetworkManager. Once that's figured out, we can discuss how to show that information. The code needs to integrate with various NetworkManager features, such as The code already integrates with VPNs. VPNs and connectivity checking. Adding any UI for network information provided via a side-channel would be premature. Could you elaborate how/why is the source of information tied to the UI? I suspect that networkd and others might not be very happy if the NetworkManager has to be available just to pass the information from whatever tool doing the actual job to the UI. Could you please explain how can we do that in environments without NetworkManager? -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 18.06.2015 13:14, Bastien Nocera wrote: - Original Message - On 12.06.2015 19:00, Matthew Miller wrote: On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I plan to contact the GNOME folks about how they would be willing to better integrate the panel (most probably in a different form) into GNOME. I don't think we want to integrate one more panel applet. The information about the DNS security should be passed on from NetworkManager. Once that's figured out, we can discuss how to show that information. I think you should discuss with us the approach before saying that you don't want to integrate with dnssec-trigger. We don't see any reason why the information should be passed back to NM. The information can be passed or gathered from dnssec-trigger itself. We don't want to lock ourselves only to NetworkManager, since there are also other network configuration managers. The code needs to integrate with various NetworkManager features, such as VPNs and connectivity checking. Adding any UI for network information provided via a side-channel would be premature. VPNs... done like 2 years ago. From what we discussed the connectivity checking is not really perfect in NM, since it assumes that DHCP provided resolvers are in resolv.conf because NM obviously uses system's stub resolver. If there are any valid integration pieces, please be specific. I would love to see more will for cooperation from GNOME people, so we can converge to the working and well integrated solution. Vague claims that something is missing or something needs to be done, without clear reasoning is not helping anyone. Cheers -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
VPNs... done like 2 years ago. From what we discussed the connectivity checking is not really perfect in NM, since it assumes that DHCP provided resolvers are in resolv.conf because NM obviously uses system's stub resolver. If there are any valid integration pieces, please be specific. I don't want, in the Network panel, to be talking to 2 pieces of software that I'll need to aggregate myself to get a complete picture. That’s kind of surprising; users should see a view that makes sense to them, not a reflection of the underlying implementation stack. Isn’t it anyway a pretty common situation to talk to two or more services in one dialog? E.g. the sharing panel definitely talks to several services. I agree that you don’t want to talk to two pieces of software which tell you different answers to the same question—but AFAICS that should be an argument in favor of integrating with dnssec-trigger directly instead of having NetworkManager proxy (and possibly modify) everything. (Well, assuming dnssec-trigger and NM talk to each other enough to keep in sync, but the dnssec-trigger-NM interface does not need to be the same as GUI-NM nor GUI-dnssec-trigger one.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
- Original Message - On 12.06.2015 19:00, Matthew Miller wrote: On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I plan to contact the GNOME folks about how they would be willing to better integrate the panel (most probably in a different form) into GNOME. I don't think we want to integrate one more panel applet. The information about the DNS security should be passed on from NetworkManager. Once that's figured out, we can discuss how to show that information. The code needs to integrate with various NetworkManager features, such as VPNs and connectivity checking. Adding any UI for network information provided via a side-channel would be premature. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
- Original Message - Am 18.06.2015 um 15:29 schrieb Bastien Nocera: I would love to see more will for cooperation from GNOME people, so we can converge to the working and well integrated solution. Vague claims that something is missing or something needs to be done, without clear reasoning is not helping anyone. It's a network feature, it needs to be integrated in NetworkManager for WorkStation to be able to configure it, and get status from it not all workstations are using NetworkManager and/or GNOME Workstation as in Fedora Workstation, which uses both by default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
- Original Message - VPNs... done like 2 years ago. From what we discussed the connectivity checking is not really perfect in NM, since it assumes that DHCP provided resolvers are in resolv.conf because NM obviously uses system's stub resolver. If there are any valid integration pieces, please be specific. I don't want, in the Network panel, to be talking to 2 pieces of software that I'll need to aggregate myself to get a complete picture. That’s kind of surprising; users should see a view that makes sense to them, not a reflection of the underlying implementation stack. Isn’t it anyway a pretty common situation to talk to two or more services in one dialog? E.g. the sharing panel definitely talks to several services. Wrong example ;) It talks to gnome-settings-daemon's sharing plugin which hides the implementation details of how to start/stop services and the various networks. I agree that you don’t want to talk to two pieces of software which tell you different answers to the same question—but AFAICS that should be an argument in favor of integrating with dnssec-trigger directly instead of having NetworkManager proxy (and possibly modify) everything. (Well, assuming dnssec-trigger and NM talk to each other enough to keep in sync, but the dnssec-trigger-NM interface does not need to be the same as GUI-NM nor GUI-dnssec-trigger one.) And use dnssec-trigger to configure VPNs or Wi-Fi? :) We really want to talk to only one service here, and NetworkManager could provide us with per-connection settings for whether to accept insecure DNSes, configuration storage, system-wide settings, etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Am 18.06.2015 um 17:17 schrieb Bastien Nocera: - Original Message - Am 18.06.2015 um 15:29 schrieb Bastien Nocera: I would love to see more will for cooperation from GNOME people, so we can converge to the working and well integrated solution. Vague claims that something is missing or something needs to be done, without clear reasoning is not helping anyone. It's a network feature, it needs to be integrated in NetworkManager for WorkStation to be able to configure it, and get status from it not all workstations are using NetworkManager and/or GNOME Workstation as in Fedora Workstation, which uses both by default but Fedora is still an operating system and not just a runtime for GNOME BTW: fix your horrible quoting signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
- Original Message - Am 18.06.2015 um 17:17 schrieb Bastien Nocera: - Original Message - Am 18.06.2015 um 15:29 schrieb Bastien Nocera: I would love to see more will for cooperation from GNOME people, so we can converge to the working and well integrated solution. Vague claims that something is missing or something needs to be done, without clear reasoning is not helping anyone. It's a network feature, it needs to be integrated in NetworkManager for WorkStation to be able to configure it, and get status from it not all workstations are using NetworkManager and/or GNOME Workstation as in Fedora Workstation, which uses both by default but Fedora is still an operating system and not just a runtime for GNOME Other spins can state their own requirements, that's the one from Fedora Workstation and/or GNOME's side. BTW: fix your horrible quoting My horrible MUA. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Mon, 2015-06-15 at 14:57 +0200, Petr Spacek wrote: On 12.6.2015 18:53, Dan Williams wrote: On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek 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. Okay, let's start once again from scratch. All of this was already discussed and we even had a huge meeting around DevConf and FLOCK 2014 about this, so following text will be just a short refresher: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. The ultimate goal = Make various man-in-the-middle attacks *automatically* detectable - without any user interaction. Especially we want to get rid of dialogs like Site www.gmail.com is using certificate issued for xxx.porn and certificate's validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]. Tools = To achieve this goal we need to do DNSSEC validation on every client machine (ignoring Docker for a moment, see below) and allow applications to use DNS as trusted source of sensitive data (certificate fingerprints, SSH fingerprints, etc.). DNSSEC allows all parties to publish their fingerprints in DNS and gives us a secure way to get the data and to detect that someone prevents us from getting the data. Longer description == http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/ First step: DNSSEC validation = Contemporary networks are full of broken DNS proxies so we need to jump through various hoops to get non-faked DNSSEC data for DNSSEC validation. The goal of this step is to get *cryptographical* proof that the data we received are the same as DNS zone owner published. This includes two sub-problems: a) Hot-spots: Captive portal detection needs to allow user to disable all the security so he can log-in but this needs to be done in a secure and reliable way so an attacker cannot misuse this. b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? All these sub-problems (including VPN handling an so on) are solved by dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda. HERE we need to coordinate with other parties who might want to write into the /etc/resolv.conf file. These include (but might not be limited to): NetworkManager initscripts dhclient libreswan ? resolved connman pppd, vpnc, openvpn, etc. should get added to the list since they all have scripts that can potentially write to /etc/resolv.conf. Option is either to implement all the checks and workarounds in all the projects over and over or to implement all the logic in one place - dnssec-trigger might be such place. Anyone who is going to write to resolv.conf needs to check for captive portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS servers and domains. *Questions:* Guys, what are your plans for handling the situations mentioned above? Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? This is the real issue. It sounds like What you're proposing is to make dnssec-trigger into the DNS broker. The previous solutions (resolvconf, NetworkManager, etc) have all failed for various reasons. Touching/changing something so fundamental to the system, as you've probably discovered, can be hard... systemd-resolved might have a chance here, since it's small and pretty simple, but they don't have an external API and don't seem interested in creating one any time soon which
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 14:32 -0400, Paul Wouters wrote: 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) Hmm, that doesn't really allow for split DNS though since it uses the resolv.conf format? Ideally we could just send unbound a list of server +domain, and then a fallback of server+* for anything not matching that list. 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 =
Re: F23 System Wide Change: Default Local DNS Resolver
On Wed, 2015-06-17 at 13:17 +0200, Tomas Hozza wrote: On 12.06.2015 18:58, Dan Williams wrote: On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote: On 11.06.2015 22:48, Dan Williams 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. NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. Correct, and I personally have no problem with this. NM is quite happy to hand off DNS information wherever it has been told to do so. But this is separate from the connectivity detection/hotspot issue which I think we'll discuss more below. The cases when local (to the network you are connected to) DNS resolver does not support DNSSEC is handled by the logic in dnssec-trigger and dnssec-trigger script. Unbound is always configured in a way that it is able to do DNS resolution and DNSSEC validation. If this can not be done, the user is informed. Right, and that's where most of this discussion lies, I think. 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. If there is such situation, that Unbound fails all DNS lookups, then it is a bug. This is pure theory until you have some real situation. The logic is designed in a way to prevent such situations from ever happen. Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done by putting DHCP provided resolvers into resolv.conf. So in this situation Unbound it not used at all. 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. 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 1.1. Dispatch dispatcher with the network configuration change event. 2. NM updates DNS information NM is not expected to touch resolv.conf in the intended default configuration. My #2 was intended to be the same as your #1.1. I was assuming dns=unbound here. 3. NM waits for some signal from unbound/dnssec-trigger about the trustability of the DNS server If you think NM needs to do some action (as I don't), we don't have problem with notifying NM (if you provide some API). NM may need to do some action for connectivity checking. 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? The only trusted DNS resolver is the local Unbound. The DNS resolver from the network you are connected to is never trusted. It is just used in case it can provide all the necessary information to do the DNSSEC validation. Since using such data we are able to build the chain of trust and verify that the Answer is correct, there is no point in distinguishing if network provided resolver is
Re: F23 System Wide Change: Default Local DNS Resolver
On Thu, 18 Jun 2015, Dan Williams wrote: 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) Hmm, that doesn't really allow for split DNS though since it uses the resolv.conf format? Ideally we could just send unbound a list of server +domain, and then a fallback of server+* for anything not matching that list. that's tricky. What you'd do with a bunch of intermediate work queries. You are probably better of splitting the work: import unbound ctxgoogle = unbound.ub_ctx() ctxgoogle.set_fwd(8.8.8.8) ctxlocal = ctx = unbound.ub_ctx() ctxlocal = ctx.resolvconf(/this/networks/respresentation/of/resolv.conf) and you can query using google: ctxgoogle.resolve(www.google.com, unbound.RR_TYPE_A) or your local setup: ctxlocal.resolve(www.google.com, unbound.RR_TYPE_A) I'm pretty sure though there will be equivalent python code that causes the same as: unbound-control forward_add fedoraproject.org 1.2.3.4 5.6.7.8 or if there isn't, that upstream wouldn't mind making that available. something like this: 0) resolve.conf/unbound/whatever DNS is unpopulated 1) NetworkManager looks up connectivity server IP address 2) NetworkManager does the connectivity check using that IP address 3) assuming either #1 or #2 fails, NM signals HOTSPOT connectivity state and provides the DNS information via the API, including any DHCP/WISPR information received from the network 4) Hotspot agent (GNOME Shell, KDE, whatever) sees the HOTSPOT state, reads the DNS servers, and spawns a sandboxed web browser using the preliminary DNS servers 5) User completes hotspot logon or rejection, user agent signals that hotspot operations complete 6) NetworkManager re-does connectivity checks, and assuming the result is success, indicates CONNECTED connectivity state or something like that. Yes. But these steps could be split out into a small, single-purpose connectivityd that used information from NM/other sources and was triggered by NM/other sources, and then NM wouldn't have to do it. NM could still proxy the state since NM would know when to trigger connectivity checks anyway. But I digress. Sure. 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 This is the part that I feel like unbound should do, or if not unbound then whatever local caching nameserver we do have. Perhaps that's already built into unbound and only controlled by dnssec-trigger, but it seems like something more integral to the resolver than outside of it? No that is the core functionality of dnssec-trigger, not unbound. We might be able to turn that into libdnssectrigger or something for re-use. I don't think upstream wants to converge these two things into one. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Thu, 18 Jun 2015, Dan Williams wrote: The drawbacks I see to dnssec-trigger here are: 2) provides only HTTPS IPC, perhaps because it works on all platforms. But a Linux-only solution would typically use a unix socket or D-Bus and be secured by Unix or D-Bus permissions instead of using certificates. Recenyly unbound was patched to allow a local socket so we don't have to go through HTTPS. This was merged upstream. A similar patch could be adopted for dnssec-triggerd and I see now reason why (the same) upstream would refuse it. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 17.06.2015 16:22, Paul Wouters wrote: On Wed, 17 Jun 2015, Tomas Hozza wrote: While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. If you don't trust fedora infrastructure, you have more issues though Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? Yes. It is all configured in /etc/dnssec-trigger/dnssec-triggerd.conf The fallback infrastructure is used as the last resort of DNS data source. Full recursion is preferred over the fallback servers. And full recursion means your privacy might be in even more danger too until the IETF dprive comes up with DNS privacy protocols. If someone is trusting a DNS server without using DNSSEC, that that person is not really aware of the potential security implications of such name resolution. With DNSSEC validation done locally, it is irrelevant what DNS servers are uses, as long they can provide all the DNSSEC data. I think DNS privacy was the issue here, not security. Eg the fact that fedora servers see your DNS queries for evil.com. There are no logs kept of queries to these servers. I think we would discontinue the service before adding logging to them. It is not like Fedora infrastructure is collecting data about which user is resolving which name. Although ANY DNS service provider can do that! If user wants to use broken nameservers, they can switch the dnssec-trigger to hotspot sign-on mode. I agree that this is completely not intuitive and should be rather named insecure mode. Practically this means that the DHCP provided resolvers are placed into resolv.conf and the user is free to shoot themselves into the feet. And your VPN DNS forwards are no longer used, so if you have a VPN up, then going into insecure mode means your network behind the VPN becomes basically unreachable. The hotspot/insecure mode is not a dont trust fedora mode. People should not use that way. Right, although it would be technically possible to also add VPN resolvers to resolv.conf in hotspot signon mode it is not the goal of the mode. Also turning off the dnssec-triggerd.service is a solution, since it will clean up after itself and return back the system to the original state. Of course you can remove it if you wish :) But that would affect all users. Granted, we are probably talking about private laptops here. But in theory one should disable dnssec-trigger-panel on a per-user basis, and not stop the system service. Right, I meant it for the single-user machine. Disabling the panel will not turn off the dnssec-trigger itself, so I don't think it would solve anything other than getting rid of the UI popup windows. systemd-resolved plans to do just a kind of best effort DNSSEC, at least from what I asked on the Linux PLumbers Conference in Dusseldorf last year on the Tom Gundersen's presentation. This means they will do the validation, but only if they are able to. They don't plan and don't want to do any fallback to external infrastructure, but rather want to turn off the validation. I'm not sure if this is still the case, but it was. This is exactly what we don't want to do with dnssec-trigger and Unbound. We will try really hard to do DNSSEC validation. A design that will just turn it off DNSSEC, possibly even silenly, seems like the wrong approach. I assume we are misunderstanding the systemd-resolvd goals here, and will let the systemd people explain their design. I hope, too. :) If this is indeed what you're proposing, then lets have a discussion about dnssec-trigger+unbound in that context, I do have some thoughts to contribute here. Good, we are open to thoughts and ideas ;) Indeed, I'm curious to what others have to say. Clearly, I have a somewhat strong bias toward DNSSEC :) Paul Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 19:17, Paul Wouters wrote: On 06/12/2015 12:53 PM, Dan Williams wrote: b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? The fallbacks are configured in /etc/dnssec-trigger/dnssec-triggerd.conf # Provided by fedoraproject.org, #fedora-admin # It is provided on a best effort basis, with no service guarantee. ssl443: 140.211.169.201 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 140.211.169.201 ssl443: 66.35.62.163 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 66.35.62.163 ssl443: 152.19.134.150 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 152.19.134.150 ssl443: 2610:28:3090:3001:dead:beef:cafe:fed9 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64 :AA:87:E6:F2 tcp80: 2610:28:3090:3001:dead:beef:cafe:fed9 Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? This is the real issue. It sounds like What you're proposing is to make dnssec-trigger into the DNS broker. The previous solutions (resolvconf, NetworkManager, etc) have all failed for various reasons. Touching/changing something so fundamental to the system, as you've probably discovered, can be hard... But it must be done for security reasons. systemd-resolved might have a chance here, since it's small and pretty simple, but they don't have an external API and don't seem interested in creating one any time soon which severely limits it's usefulness. And last I looked it did not support DNSSEC. I'm also weary about systemd-resolved basically marshalling DNS via DBUS. If this is indeed what you're proposing, then lets have a discussion about dnssec-trigger+unbound in that context, I do have some thoughts to contribute here. I believe we selected dnssec-trigger because it was the UI/daemon that worked. A better native integration into either NM or Gnome would be preferred. I had the same idea before, but given that there is not only NM, but also other projects that intend to do the same thing as NM and even replace it in some environments (e.g. systemd-networkd) I don't think it makes sense to implement the same thing in each and every of these. I changed my mind and think that having one component implementing the functionality and communicating with the network configuration software that is used on the specific platform is a better approach. Although dnssec-trigger may not be ideal as final solution, it is a good for start and as a proof of concept of how to do client side DNSSEC validation properly. Tomas Paul -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 18:58, Dan Williams wrote: On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote: On 11.06.2015 22:48, Dan Williams 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. NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. Correct, and I personally have no problem with this. NM is quite happy to hand off DNS information wherever it has been told to do so. But this is separate from the connectivity detection/hotspot issue which I think we'll discuss more below. The cases when local (to the network you are connected to) DNS resolver does not support DNSSEC is handled by the logic in dnssec-trigger and dnssec-trigger script. Unbound is always configured in a way that it is able to do DNS resolution and DNSSEC validation. If this can not be done, the user is informed. Right, and that's where most of this discussion lies, I think. 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. If there is such situation, that Unbound fails all DNS lookups, then it is a bug. This is pure theory until you have some real situation. The logic is designed in a way to prevent such situations from ever happen. Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done by putting DHCP provided resolvers into resolv.conf. So in this situation Unbound it not used at all. 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. 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 1.1. Dispatch dispatcher with the network configuration change event. 2. NM updates DNS information NM is not expected to touch resolv.conf in the intended default configuration. My #2 was intended to be the same as your #1.1. I was assuming dns=unbound here. 3. NM waits for some signal from unbound/dnssec-trigger about the trustability of the DNS server If you think NM needs to do some action (as I don't), we don't have problem with notifying NM (if you provide some API). NM may need to do some action for connectivity checking. 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? The only trusted DNS resolver is the local Unbound. The DNS resolver from the network you are connected to is never trusted. It is just used in case it can provide all the necessary information to do the DNSSEC validation. Since using such data we are able to build the chain of trust and verify that the Answer is correct, there is no point in distinguishing if network provided resolver is trusted or not... it is not. This is the reason we do the validation locally. Ok, I should rephrase my question to be clearer. NM's connectivity checking
Re: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 16:58, Paul Wouters wrote: On Fri, 12 Jun 2015, Matthew Miller wrote: Another integration concern: the network config GUI (and ifcfg files, for that matter) let me list specific DNS servers. With this feature, are those used (and if so, how)? If not, is my configuration just silently ignored? I do not know if it is supported currently, but support for that is very trivial. If unbound is found running, issue: unbound-control forward_add . 1.2.3.4 5.6.7.8 I'm not sure whose job that would be. Paul This should be ideally left to the network configuration software (e.g. NM). Dnssec-trigger will not touch any forward zones that are already configured in Unbound and it didn't configured them itself. While technically this should not be a problem, and everything should work properly (since forward zones are configured properly), this should be ideally done only by the dnssec-trigger based on the information passed by VPN to the NM. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 18:53, Dan Williams wrote: On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek 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. Okay, let's start once again from scratch. All of this was already discussed and we even had a huge meeting around DevConf and FLOCK 2014 about this, so following text will be just a short refresher: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. The ultimate goal = Make various man-in-the-middle attacks *automatically* detectable - without any user interaction. Especially we want to get rid of dialogs like Site www.gmail.com is using certificate issued for xxx.porn and certificate's validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]. Tools = To achieve this goal we need to do DNSSEC validation on every client machine (ignoring Docker for a moment, see below) and allow applications to use DNS as trusted source of sensitive data (certificate fingerprints, SSH fingerprints, etc.). DNSSEC allows all parties to publish their fingerprints in DNS and gives us a secure way to get the data and to detect that someone prevents us from getting the data. Longer description == http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/ First step: DNSSEC validation = Contemporary networks are full of broken DNS proxies so we need to jump through various hoops to get non-faked DNSSEC data for DNSSEC validation. The goal of this step is to get *cryptographical* proof that the data we received are the same as DNS zone owner published. This includes two sub-problems: a) Hot-spots: Captive portal detection needs to allow user to disable all the security so he can log-in but this needs to be done in a secure and reliable way so an attacker cannot misuse this. b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? The fallback infrastructure is used as the last resort of DNS data source. Full recursion is preferred over the fallback servers. If someone is trusting a DNS server without using DNSSEC, that that person is not really aware of the potential security implications of such name resolution. With DNSSEC validation done locally, it is irrelevant what DNS servers are uses, as long they can provide all the DNSSEC data. It is not like Fedora infrastructure is collecting data about which user is resolving which name. Although ANY DNS service provider can do that! If user wants to use broken nameservers, they can switch the dnssec-trigger to hotspot sign-on mode. I agree that this is completely not intuitive and should be rather named insecure mode. Practically this means that the DHCP provided resolvers are placed into resolv.conf and the user is free to shoot themselves into the feet. Also turning off the dnssec-triggerd.service is a solution, since it will clean up after itself and return back the system to the original state. Of course you can remove it if you wish :) All these sub-problems (including VPN handling an so on) are solved by dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda. HERE we need to coordinate with other parties who might want to write into the /etc/resolv.conf file. These include (but might not be limited to): NetworkManager initscripts dhclient libreswan ? resolved connman pppd, vpnc, openvpn, etc. should get added to the list since they all have scripts that can potentially write to /etc/resolv.conf. Option is either to implement all the checks and workarounds in all the projects over and over or to implement all the logic in one place - dnssec-trigger
Re: F23 System Wide Change: Default Local DNS Resolver
On 12.06.2015 19:00, Matthew Miller wrote: On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I plan to contact the GNOME folks about how they would be willing to better integrate the panel (most probably in a different form) into GNOME. I understand Hotspot sign-on and can go from there, but I can't see it not completely perplexing e.g. my dad. I agree that something like insecure mode would be more self-explanatory. I don't know what Reprobe does (and especially not because there's no context other than the anchor), and Probe Results give some indication that it has to do with DNSSEC — but I think that if our users have to learn what that means and understand all that in order to be secure (or just to browse the web at _any_ level), we're not succeeding. I hope we can get a design for this which integrates better with GNOME Shell and the existing network icon there. I hope too. Regards, Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Wed, 17 Jun 2015, Tomas Hozza wrote: While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. If you don't trust fedora infrastructure, you have more issues though Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? Yes. It is all configured in /etc/dnssec-trigger/dnssec-triggerd.conf The fallback infrastructure is used as the last resort of DNS data source. Full recursion is preferred over the fallback servers. And full recursion means your privacy might be in even more danger too until the IETF dprive comes up with DNS privacy protocols. If someone is trusting a DNS server without using DNSSEC, that that person is not really aware of the potential security implications of such name resolution. With DNSSEC validation done locally, it is irrelevant what DNS servers are uses, as long they can provide all the DNSSEC data. I think DNS privacy was the issue here, not security. Eg the fact that fedora servers see your DNS queries for evil.com. There are no logs kept of queries to these servers. I think we would discontinue the service before adding logging to them. It is not like Fedora infrastructure is collecting data about which user is resolving which name. Although ANY DNS service provider can do that! If user wants to use broken nameservers, they can switch the dnssec-trigger to hotspot sign-on mode. I agree that this is completely not intuitive and should be rather named insecure mode. Practically this means that the DHCP provided resolvers are placed into resolv.conf and the user is free to shoot themselves into the feet. And your VPN DNS forwards are no longer used, so if you have a VPN up, then going into insecure mode means your network behind the VPN becomes basically unreachable. The hotspot/insecure mode is not a dont trust fedora mode. People should not use that way. Also turning off the dnssec-triggerd.service is a solution, since it will clean up after itself and return back the system to the original state. Of course you can remove it if you wish :) But that would affect all users. Granted, we are probably talking about private laptops here. But in theory one should disable dnssec-trigger-panel on a per-user basis, and not stop the system service. systemd-resolved plans to do just a kind of best effort DNSSEC, at least from what I asked on the Linux PLumbers Conference in Dusseldorf last year on the Tom Gundersen's presentation. This means they will do the validation, but only if they are able to. They don't plan and don't want to do any fallback to external infrastructure, but rather want to turn off the validation. I'm not sure if this is still the case, but it was. This is exactly what we don't want to do with dnssec-trigger and Unbound. We will try really hard to do DNSSEC validation. A design that will just turn it off DNSSEC, possibly even silenly, seems like the wrong approach. I assume we are misunderstanding the systemd-resolvd goals here, and will let the systemd people explain their design. If this is indeed what you're proposing, then lets have a discussion about dnssec-trigger+unbound in that context, I do have some thoughts to contribute here. Good, we are open to thoughts and ideas ;) Indeed, I'm curious to what others have to say. Clearly, I have a somewhat strong bias toward DNSSEC :) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Tue, 16 Jun 2015, Bastien Nocera wrote: That’s what dnssec-trigger ideally _should_ do. What would it _actually_ do, e.g. with the current code? That's defined by login-command: in /etc/dnssec-trigger/dnssec-trigger.conf which we did not change from the default xdg-open. It uses the URL configured by login-location: for which we use: http://hotspot-nocache.fedoraproject.org/; xdg-open could be changed to a user's firefox, or a private window firefox, or chrome, etc etc. As what user is that trigger run? It is run by dnssec-trigger-panel which runs as the logged in user. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
- Original Message - On Mon, 15 Jun 2015, Miloslav Trmač wrote: Detect it and show the sandboxed browser. If that means that the user has to type their Facebook password again, then the user is welcome to do that. I don't see why we should make it easier to track users, though. That’s what dnssec-trigger ideally _should_ do. What would it _actually_ do, e.g. with the current code? That's defined by login-command: in /etc/dnssec-trigger/dnssec-trigger.conf which we did not change from the default xdg-open. It uses the URL configured by login-location: for which we use: http://hotspot-nocache.fedoraproject.org/; xdg-open could be changed to a user's firefox, or a private window firefox, or chrome, etc etc. As what user is that trigger run? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 12.6.2015 16:55, Dan Williams wrote: On Fri, 2015-06-12 at 10:20 -0400, Matthew Miller wrote: On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote: NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. Another integration concern: the network config GUI (and ifcfg files, for that matter) let me list specific DNS servers. With this feature, are those used (and if so, how)? If not, is my configuration just silently ignored? NM will use those DNS servers as it always has, and with dns=unbound will simply forward them to unbound, which will use your servers as the upstream servers. Basically, any information that NM used to write to resolv.conf will now instead get forwarded to unbound. What unbound wants to do with it is another story, of course, that I'm not an expert on but Thomas/Paul/etc are. This scenario should work fine. Generally we need to get all tools to push the DNS servers to NM (so somewhere else) so the information is available via (e.g.) NM API. That is ideal case which would allow us to centralize DNSSEC handling on one place in dnssec-triggerd. -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 12.6.2015 18:53, Dan Williams wrote: On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek 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. Okay, let's start once again from scratch. All of this was already discussed and we even had a huge meeting around DevConf and FLOCK 2014 about this, so following text will be just a short refresher: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. The ultimate goal = Make various man-in-the-middle attacks *automatically* detectable - without any user interaction. Especially we want to get rid of dialogs like Site www.gmail.com is using certificate issued for xxx.porn and certificate's validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]. Tools = To achieve this goal we need to do DNSSEC validation on every client machine (ignoring Docker for a moment, see below) and allow applications to use DNS as trusted source of sensitive data (certificate fingerprints, SSH fingerprints, etc.). DNSSEC allows all parties to publish their fingerprints in DNS and gives us a secure way to get the data and to detect that someone prevents us from getting the data. Longer description == http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/ First step: DNSSEC validation = Contemporary networks are full of broken DNS proxies so we need to jump through various hoops to get non-faked DNSSEC data for DNSSEC validation. The goal of this step is to get *cryptographical* proof that the data we received are the same as DNS zone owner published. This includes two sub-problems: a) Hot-spots: Captive portal detection needs to allow user to disable all the security so he can log-in but this needs to be done in a secure and reliable way so an attacker cannot misuse this. b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? All these sub-problems (including VPN handling an so on) are solved by dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda. HERE we need to coordinate with other parties who might want to write into the /etc/resolv.conf file. These include (but might not be limited to): NetworkManager initscripts dhclient libreswan ? resolved connman pppd, vpnc, openvpn, etc. should get added to the list since they all have scripts that can potentially write to /etc/resolv.conf. Option is either to implement all the checks and workarounds in all the projects over and over or to implement all the logic in one place - dnssec-trigger might be such place. Anyone who is going to write to resolv.conf needs to check for captive portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS servers and domains. *Questions:* Guys, what are your plans for handling the situations mentioned above? Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? This is the real issue. It sounds like What you're proposing is to make dnssec-trigger into the DNS broker. The previous solutions (resolvconf, NetworkManager, etc) have all failed for various reasons. Touching/changing something so fundamental to the system, as you've probably discovered, can be hard... systemd-resolved might have a chance here, since it's small and pretty simple, but they don't have an external API and don't seem interested in creating one any time soon which severely limits it's usefulness. If this is indeed what you're proposing, then lets have a discussion about dnssec-trigger+unbound in that context, I do have some thoughts to
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Mon, 15 Jun 2015, Miloslav Trmač wrote: Detect it and show the sandboxed browser. If that means that the user has to type their Facebook password again, then the user is welcome to do that. I don't see why we should make it easier to track users, though. That’s what dnssec-trigger ideally _should_ do. What would it _actually_ do, e.g. with the current code? That's defined by login-command: in /etc/dnssec-trigger/dnssec-trigger.conf which we did not change from the default xdg-open. It uses the URL configured by login-location: for which we use: http://hotspot-nocache.fedoraproject.org/; xdg-open could be changed to a user's firefox, or a private window firefox, or chrome, etc etc. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On 13 June 2015 at 17:10, Michael Catanzaro mcatanz...@gnome.org wrote: On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote: If the captive portal uses the system's DNS, and the system has cached www.gnome.org from when you were on a previous network, your captive portal check might use a cached DNS resolve and try to use an HTTP connection to a blocked IP address, because the local forged DNS answer to the local hotspot IP never got triggered. Thanks. I am still trying to understand this fully. I assumed the portal would hijack TCP connections, but if the portal uses DNS hijacking only and does not hijack TCP connections to the real www.gnome.org, and we attempt to open a TCP session to the real www.gnome.org, and the portal is only expecting us to visit a different host due to its DNS hijacking, then I understand that we're out of luck and the portal's login page will never show. OK, I've followed that far. There is one thing I don't understand. Surely the above is exactly what will happen if you were to get stuck behind a captive portal with Firefox or any normal browser? But portals still work reliably for users. So either the browsers are doing a connectivity test similar to what you described (to a host with a DNS TTL of 0) and we have to do it too, or the portals are prepared to hijack TCP connections and not just DNS and we have no problem, or the portals just don't work reliably for browsers and portal-helper is an opportunity to fix that. Right...? Think of every way that someone has ever set up a GNOME desktop to do something that you didn't plan.. and now take the factorial of that number... and you will probably be close to the numbers of ways 'captive' portals have been set up in the real world. I have seen the following as ways captivity is setup: 1) A strange ipv4-to-ipv6 item. If you tried to go out native in ipv6 it was allowed.. but all ipv4 got converted to ipv6 and then back to ipv4 on the regular internet. 2) A weird satellite system that converted tcp2udp and udp and icmp were allowed out naked. 3) multiple systems all supposedly using some industry standard but not reacting in the same way. 4) systems which allowed everything but 25/80/443 until you dealt with the capture. 5) systems which allow for N packets on any port but after that number block everything until you have verified. 6) systems which put you on the capture vlan and all dns goes to some 10.0.0.1 ip until you are verified and then puts you through a Nat on Nat vlan to get the internet. Is the code on how ChromeOS or Android detects captivity part of the 'public' code? It seems to do a 'good' job in finding many captive portals so might be something to get an idea on how many weird ways things are out there. Anyway, once I understand this properly, I will file a bug upstream (or if you have a GNOME Bugzilla account, it would be better if you do so, to be CCed on responses). Thanks for catching this issue. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Mon, 15 Jun 2015, Stephen John Smoogen wrote: Is the code on how ChromeOS or Android detects captivity part of the 'public' code? It seems to do a 'good' job in finding many captive portals so might be something to get an idea on how many weird ways things are out there. I think everyone does it similarly. Apple, Google, etc. You have a web server with a guarantee on no HTTP redirect. You expect some specific content, typicall OK to be there in the proper mime type. (usually text) If you get different text or a redirect or other error (eg forbidden) then you assume you're in a captive portal. Apple (foolishly) used to use something like http://apple.com/hotspot on their main site itself, which meant that using a VPN on demand could never protect apple.com because the iphone had to leave that domain out of the vpn trigger list or else all hotspot detection would be broken. It seems they have switched to captive.apple.com with returns Success. It has a TTL of 10 (after a CNAME redirect into Akamai) but it is missing a record. Guess there aren't many ipv6 captive portals yet :P Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On 15 June 2015 at 13:07, Paul Wouters p...@nohats.ca wrote: On Mon, 15 Jun 2015, Stephen John Smoogen wrote: Is the code on how ChromeOS or Android detects captivity part of the 'public' code? It seems to do a 'good' job in finding many captive portals so might be something to get an idea on how many weird ways things are out there. I think everyone does it similarly. Apple, Google, etc. I expect so. I was mainly asking because code usually speaks louder than words for developers and so Michael would have a better ability to see what things other groups doing this have run into and why it isn't simple. You have a web server with a guarantee on no HTTP redirect. You expect some specific content, typicall OK to be there in the proper mime type. (usually text) If you get different text or a redirect or other error (eg forbidden) then you assume you're in a captive portal. Apple (foolishly) used to use something like http://apple.com/hotspot on their main site itself, which meant that using a VPN on demand could never protect apple.com because the iphone had to leave that domain out of the vpn trigger list or else all hotspot detection would be broken. It seems they have switched to captive.apple.com with returns Success. It has a TTL of 10 (after a CNAME redirect into Akamai) but it is missing a record. Guess there aren't many ipv6 captive portals yet :P Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Mon, Jun 15, 2015 at 12:07 PM, Paul Wouters p...@nohats.ca wrote: On Mon, 15 Jun 2015, Stephen John Smoogen wrote: Is the code on how ChromeOS or Android detects captivity part of the 'public' code? It seems to do a 'good' job in finding many captive portals so might be something to get an idea on how many weird ways things are out there. I think everyone does it similarly. Apple, Google, etc. You have a web server with a guarantee on no HTTP redirect. You expect some specific content, typicall OK to be there in the proper mime type. (usually text) If you get different text or a redirect or other error (eg forbidden) then you assume you're in a captive portal. Apple (foolishly) used to use something like http://apple.com/hotspot on their main site itself, which meant that using a VPN on demand could never protect apple.com because the iphone had to leave that domain out of the vpn trigger list or else all hotspot detection would be broken. It seems they have switched to captive.apple.com with returns Success. It has a TTL of 10 (after a CNAME redirect into Akamai) but it is missing a record. Guess there aren't many ipv6 captive portals yet :P Using http://apple.com/[anything] is an extra-terrible idea because it's rather fundamentally incompatible with HSTS unless you fudge it client-side to ignore HSTS. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač m...@redhat.com wrote: What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider deliberately let the hotspot probe lookup and connection through, but kept redirecting everything else? Detect it and show the sandboxed browser. If that means that the user has to type their Facebook password again, then the user is welcome to do that. I don't see why we should make it easier to track users, though. That’s what dnssec-trigger ideally _should_ do. What would it _actually_ do, e.g. with the current code? Or we could proxy all traffic through the giant hole they'll create in order to avoid being detected as a captive portal. /me ducks Nice ☺ More realistically, we could proxy the DNS fallback through there. We could at least make these shenanigans harder by sending a legitimate-looking UA header Yes and hitting a non-static page that answers some challenge rather than just saying 200 OK. I don’t think that would help; the hotspots tend to use a whitelist of “don’t intercept” addresses (which is after all easier than completely faking even a static reply), so seeing an unmodified hotspot detection page does not say anything about other pages being modified. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Generally the problem is that resolv.conf is quite limited and cannot express lot of things, like trust levels and per-domain forwarding (using different servers for queries related to different domains). One possibility how to solve this is to port applications to use different library/API for name resolution but we have learn that this is not feasible (recall the everything to NSS effort). The NSS consolidation lessons don’t quite apply because the essential requirement of that was “everything will use a single implementation” which is not actually a requirement in this case: it is only “everything will talk to the correct same resolver and will have the same assumptions about it being trusted for DNSSEC validation”. So one option you haven’t mentioned is: Keep all the current resolver libraries and their APIs, but modify their implementations to take their configuration from a different source; and have the local unbound, if any, use /etc/resolf.conf (along with other configuration sources?). If possible, this would be very nice in that it would allow us to keep /etc/resolv.conf as the _administrator_-targeted configuration file where the external/forwarding DNS resolvers are configured, while keeping the _internal implementation_-focused state (availability and address of the trusted local resolver, an implementation detail of DNSSEC rather than an administrator-visible configuration item) invisible/less visible to administrators, and in fact not even a part of API of any of the resolver libraries, and it would minimize users’ disruption. As it is now, we will end up with this weird “configuration” file in /etc which looks like just any other configuration file except this one is both _not_ user modifiable _and_ cannot be just removed. From the various small code snippets in this thread and elsewhere it seems that doing this would probably not be possible because the knowledge that “/etc/resolv.conf is where I read which resolver to send packets to” has leaked from the libraries to the applications, so merely patching resolvers would be insufficient. (And, honestly, ABIs should be code interfaces and not file formats, so I will not mourn for editable /etc/resolv.conf too much…) But, well, just in case it were actually possible… Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
Hello, On Jun 13, 2015 4:28 AM, Michael Catanzaro mcatanz...@gnome.org wrote: On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote: But that's not even right. Suppose you have a captive portal that wants you to log in via your Google account. It can send you do https://accounts.google.com , and your browser can verify the certificate and show you an indication that the connection is secure. Then you really can safely enter your password. Hmmm, I didn't realize legitimate portals might take you to the public Internet. I think I've seen this in airports and in some hotel chains. Yes; sadly, many “legitimate portals” (easily 50% of the airport hotspots I have encoutered in Europe) are pretty much attackers. In particular, many of them want to bypass hotspot detection so that the log in screen does not appear in the sandboxed hotspot sign-on browser; by now it is a pretty standard feature of business access points to have a “bypass hotspot detection” checkbox. (For iOS, this has reportedly been done by recognizing an unique User-Agent used for the hotspot check; not sure about Android.)¹ They want to use the regular, unsandboxed, browser so that * password autofill works * credit card number autofill works * your Facebook login state is available to that you can easily “like” the hotspot provider (I’m not entirely sure but I think I did already see “like our page for 15 minutes of free internet” in a public hotspot) * your advertising tracking cookies transfer (for better targeting of ads on the hotspot login page, or so that you can be marked “visited airport $ABC” and related ads can be targeted at you in the future) What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider deliberately let the hotspot probe lookup and connection through, but kept redirecting everything else? Mirek ¹ You can guess what this does to any applications which use unauthenticated HTTP to download data in the background: all that data suddenly becomes the hotspot login page and the application may not realize there is anything suspect about it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač m...@redhat.com wrote: Hello, On Jun 13, 2015 4:28 AM, Michael Catanzaro mcatanz...@gnome.org wrote: On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote: But that's not even right. Suppose you have a captive portal that wants you to log in via your Google account. It can send you do https://accounts.google.com, and your browser can verify the certificate and show you an indication that the connection is secure. Then you really can safely enter your password. Hmmm, I didn't realize legitimate portals might take you to the public Internet. I think I've seen this in airports and in some hotel chains. Yes; sadly, many “legitimate portals” (easily 50% of the airport hotspots I have encoutered in Europe) are pretty much attackers. In particular, many of them want to bypass hotspot detection so that the log in screen does not appear in the sandboxed hotspot sign-on browser; by now it is a pretty standard feature of business access points to have a “bypass hotspot detection” checkbox. (For iOS, this has reportedly been done by recognizing an unique User-Agent used for the hotspot check; not sure about Android.)¹ They want to use the regular, unsandboxed, browser so that password autofill works credit card number autofill works your Facebook login state is available to that you can easily “like” the hotspot provider (I’m not entirely sure but I think I did already see “like our page for 15 minutes of free internet” in a public hotspot) your advertising tracking cookies transfer (for better targeting of ads on the hotspot login page, or so that you can be marked “visited airport $ABC” and related ads can be targeted at you in the future) What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider deliberately let the hotspot probe lookup and connection through, but kept redirecting everything else? Mirek Detect it and show the sandboxed browser. If that means that the user has to type their Facebook password again, then the user is welcome to do that. I don't see why we should make it easier to track users, though. Or we could proxy all traffic through the giant hole they'll create in order to avoid being detected as a captive portal. /me ducks We could at least make these shenanigans harder by sending a legitimate-looking UA header and hitting a non-static page that answers some challenge rather than just saying 200 OK. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
Apple (foolishly) used to use something like http://apple.com/hotspot on their main site itself, which meant that using a VPN on demand could never protect apple.com because the iphone had to leave that domain out of the vpn trigger list or else all hotspot detection would be broken. It seems they have switched to captive.apple.com with returns Success. Nowadays they randomly? choose from several different domains. See e.g. http://help.tanaza.com/customer/portal/articles/1317023-captive-portal-automatic-detection-avoid-login-popups . Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Sat, 13 Jun 2015, Michael Catanzaro wrote: There is one thing I don't understand. Surely the above is exactly what will happen if you were to get stuck behind a captive portal with Firefox or any normal browser? But portals still work reliably for users. You should visit more hotels. The number of different bugs and features has turned the phrase hotel network into a decoratory term. The interaction with normal browsers have their own weirdness. For example, if i use the url 1.2.3.4 at Starbucks, and go to another coffeeshop later on, and type 1.2.3.4 again, it shows me the cached starbucks page. While the SecondCup page uses some always reachable page, so I could pick it up from my browser history without actually needing to worry about DNS mangling, as my browser isn't using DNS because it is cached (to go to 10.128.128.128) A throw away browser with no DNS of WEB cache would really be preferred. So either the browsers are doing a connectivity test similar to what you described (to a host with a DNS TTL of 0) and we have to do it too, or the portals are prepared to hijack TCP connections and not just DNS and we have no problem, or the portals just don't work reliably for browsers and portal-helper is an opportunity to fix that. Right...? That would be logical. Hotel networks rarely are :P You're at the mercy of arp spoofing/poisoning, fragmentation, filtering, tranparant proxies, and some serious DNS protocol violations combined with a healthy dose of packet loss. Anyway, once I understand this properly, I will file a bug upstream (or if you have a GNOME Bugzilla account, it would be better if you do so, to be CCed on responses). Thanks for catching this issue. I am not sure, but if I do I haven't really used it. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote: If the captive portal uses the system's DNS, and the system has cached www.gnome.org from when you were on a previous network, your captive portal check might use a cached DNS resolve and try to use an HTTP connection to a blocked IP address, because the local forged DNS answer to the local hotspot IP never got triggered. Thanks. I am still trying to understand this fully. I assumed the portal would hijack TCP connections, but if the portal uses DNS hijacking only and does not hijack TCP connections to the real www.gnome.org, and we attempt to open a TCP session to the real www.gnome.org, and the portal is only expecting us to visit a different host due to its DNS hijacking, then I understand that we're out of luck and the portal's login page will never show. OK, I've followed that far. There is one thing I don't understand. Surely the above is exactly what will happen if you were to get stuck behind a captive portal with Firefox or any normal browser? But portals still work reliably for users. So either the browsers are doing a connectivity test similar to what you described (to a host with a DNS TTL of 0) and we have to do it too, or the portals are prepared to hijack TCP connections and not just DNS and we have no problem, or the portals just don't work reliably for browsers and portal-helper is an opportunity to fix that. Right...? Anyway, once I understand this properly, I will file a bug upstream (or if you have a GNOME Bugzilla account, it would be better if you do so, to be CCed on responses). Thanks for catching this issue. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Jun 13, 2015 4:28 AM, Michael Catanzaro mcatanz...@gnome.org wrote: On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote: But that's not even right. Suppose you have a captive portal that wants you to log in via your Google account. It can send you do https://accounts.google.com, and your browser can verify the certificate and show you an indication that the connection is secure. Then you really can safely enter your password. Hmmm, I didn't realize legitimate portals might take you to the public Internet. I think I've seen this in airports and in some hotel chains. It'd be nice to not show http://www.gnome.org (the test URL we load, expecting to be hijacked) if the portal decides not to redirect you to a new URI (not sure how common that is), but I think we will have to or we can't fix this It could be http://generic-network-login.org or something like that. I think the UI should look like a real browser except that it should clearly indicate that it's a Log in to wireless network browser in addition to showing a standard URL bar. https://bugzilla.gnome.org/show_bug.cgi?id=749197 Can you please CC me on that bug? I didn't know GNOME Bugzilla even had private bugs. :D Done. I don't think I'm the one who made it private. FWIW the tech used for GNOME apps that need a web view is WebKitGTK+. Can that provide real chrome? The web view is a GtkWidget: you pack it like any other GtkWidget into your hierarchy, and put your own chrome around it. In this case, a URL bar would not make any sense since we don't want the user changing the URL; we'll probably want to display an unmodifiable URL alongside a security indicator. I guess the reason to keep it read-only is to prevent people from using it like a real browser. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote: But that's not even right. Suppose you have a captive portal that wants you to log in via your Google account. It can send you do https://accounts.google.com, and your browser can verify the certificate and show you an indication that the connection is secure. Then you really can safely enter your password. Hmmm, I didn't realize legitimate portals might take you to the public Internet. It'd be nice to not show http://www.gnome.org (the test URL we load, expecting to be hijacked) if the portal decides not to redirect you to a new URI (not sure how common that is), but I think we will have to or we can't fix this I think the UI should look like a real browser except that it should clearly indicate that it's a Log in to wireless network browser in addition to showing a standard URL bar. https://bugzilla.gnome.org/show_bug.cgi?id=749197 Can you please CC me on that bug? I didn't know GNOME Bugzilla even had private bugs. :D FWIW the tech used for GNOME apps that need a web view is WebKitGTK+. Can that provide real chrome? The web view is a GtkWidget: you pack it like any other GtkWidget into your hierarchy, and put your own chrome around it. In this case, a URL bar would not make any sense since we don't want the user changing the URL; we'll probably want to display an unmodifiable URL alongside a security indicator. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
Am 13.06.2015 um 21:01 schrieb Michael Catanzaro: There is a good reason we started hotspot-nocache.fedoraproject.org. Hm... the captive portal helper loads www.gnome.org but it only runs after NetworkManager has decided there is a captive portal. We can make this URL configurable at build time if there's really a problem, but I'm not sure there is, since it's not used for NetworkManager's connectivity check (which is what triggers us to start the captive portal helper, and what decides that we have full Internet access and closes it). For the connectivity check, NetworkManager uses https://fedoraproject.org/static/hotspot.txt defined in /etc/NetworkManager/conf.d/20-connectivity-fedora.conf. So... I guess that is not good, and we should switch that to use hotspot -nocache.fedoraproject.org instead? surely you moust not use cached results for on-demand connectivity checks signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Sat, 13 Jun 2015, Michael Catanzaro wrote: Hm... the captive portal helper loads www.gnome.org but it only runs after NetworkManager has decided there is a captive portal. We can make this URL configurable at build time if there's really a problem, but I'm not sure there is, since it's not used for NetworkManager's connectivity check (which is what triggers us to start the captive portal helper, and what decides that we have full Internet access and closes it). For the connectivity check, NetworkManager uses https://fedoraproject.org/static/hotspot.txt defined in /etc/NetworkManager/conf.d/20-connectivity-fedora.conf. So... I guess that is not good, and we should switch that to use hotspot -nocache.fedoraproject.org instead? If the captive portal uses the system's DNS, and the system has cached www.gnome.org from when you were on a previous network, your captive portal check might use a cached DNS resolve and try to use an HTTP connection to a blocked IP address, because the local forged DNS answer to the local hotspot IP never got triggered. So if you use www.gnome.org, you have to make sure the portal software is not using the system DNS cache for DNS lookups. So it is better for captive portal login to use hotspot-nocache.fedoraproject.org, which will always have a TTL of 0, so it will not cached. For detecting whether or not you are hotspotted, the decision to say it is a hotspot is based on DNS inteception or HTTP interception, so using https://fedoraproject.org/static/hotspot.txt is fine, as it is guaranteed to never use any kind of redirects and will always just return a page stating OK. Anythign else means hotspot (or attack :) In this case, DNS caching won't matter because this part is only used for the HTTP interception test. The DNS interception test (at least with dnssec-trigger) queries the root zone and a handful of TLD queries, and does not use DNS queries for fedoraproject.org. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Sat, 13 Jun 2015, Andrew Lutomirski wrote: It'd be nice to not show http://www.gnome.org (the test URL we load, expecting to be hijacked) if the portal decides not to redirect you to a new URI (not sure how common that is), but I think we will have to or we can't fix this It could be http://generic-network-login.org or something like that. using www.gnome.org is wrong. For one, you cannot guarantee they won't end up using some redirect and than the captive portal would fail. Second, the TTL for that DNS entry is not 0, so it will get cached and cause wrong probe results later on. There is a good reason we started hotspot-nocache.fedoraproject.org. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)
On Sat, 2015-06-13 at 14:36 -0400, Paul Wouters wrote: using www.gnome.org is wrong. For one, you cannot guarantee they won't end up using some redirect and than the captive portal would fail. I don't get it: what is wrong, what would fail? We expect them to replace the contents of www.gnome.org with either their own content, or else a redirect someplace else. Second, the TTL for that DNS entry is not 0, so it will get cached and cause wrong probe results later on. There is a good reason we started hotspot-nocache.fedoraproject.org. Hm... the captive portal helper loads www.gnome.org but it only runs after NetworkManager has decided there is a captive portal. We can make this URL configurable at build time if there's really a problem, but I'm not sure there is, since it's not used for NetworkManager's connectivity check (which is what triggers us to start the captive portal helper, and what decides that we have full Internet access and closes it). For the connectivity check, NetworkManager uses https://fedoraproject.org/static/hotspot.txt defined in /etc/NetworkManager/conf.d/20-connectivity-fedora.conf. So... I guess that is not good, and we should switch that to use hotspot -nocache.fedoraproject.org instead? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 11.06.2015 22:48, Dan Williams 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. NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. The cases when local (to the network you are connected to) DNS resolver does not support DNSSEC is handled by the logic in dnssec-trigger and dnssec-trigger script. Unbound is always configured in a way that it is able to do DNS resolution and DNSSEC validation. If this can not be done, the user is informed. 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. If there is such situation, that Unbound fails all DNS lookups, then it is a bug. This is pure theory until you have some real situation. The logic is designed in a way to prevent such situations from ever happen. Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done by putting DHCP provided resolvers into resolv.conf. So in this situation Unbound it not used at all. 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. 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 1.1. Dispatch dispatcher with the network configuration change event. 2. NM updates DNS information NM is not expected to touch resolv.conf in the intended default configuration. 3. NM waits for some signal from unbound/dnssec-trigger about the trustability of the DNS server If you think NM needs to do some action (as I don't), we don't have problem with notifying NM (if you provide some API). 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? The only trusted DNS resolver is the local Unbound. The DNS resolver from the network you are connected to is never trusted. It is just used in case it can provide all the necessary information to do the DNSSEC validation. Since using such data we are able to build the chain of trust and verify that the Answer is correct, there is no point in distinguishing if network provided resolver is trusted or not... it is not. This is the reason we do the validation locally. Dan I would like to add that this already works without any other interaction with NM. I agree that the notifications from dnssec-trigger are not ideal. I'm going to contact some GNOME guys and ask them for help. Thank you for your comments! Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 11:19 -0700, Andrew Lutomirski wrote: It wouldn't really have to be Firefox, but getting the browser chrome right to avoid trivial phishing attacks is critical, and all real browsers already do that fairly well, whereas the simple embedded web views (e.g. gnome-shell-portal-helper) get it nearly 100% wrong. Hi, it sounds like we have a problem to fix in gnome-shell-portal -helper. What specifically are your requirements for the browser chrome? I figure as long as the window title is something along the lines of Connect to wireless network and the hotspot can't change that, then we should be good? We could also put a short explanation of what is going on in a GtkInfoBar to make it really stand out. I guess the goal is to make the chrome distinctive enough that a user stops to think something is not right, don't enter password when the captive portal helper appears and displays google.com. FWIW the tech used for GNOME apps that need a web view is WebKitGTK+. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, Jun 12, 2015 at 3:32 PM, Michael Catanzaro mcatanz...@gnome.org wrote: On Fri, 2015-06-12 at 11:19 -0700, Andrew Lutomirski wrote: It wouldn't really have to be Firefox, but getting the browser chrome right to avoid trivial phishing attacks is critical, and all real browsers already do that fairly well, whereas the simple embedded web views (e.g. gnome-shell-portal-helper) get it nearly 100% wrong. Hi, it sounds like we have a problem to fix in gnome-shell-portal -helper. What specifically are your requirements for the browser chrome? I figure as long as the window title is something along the lines of Connect to wireless network and the hotspot can't change that, then we should be good? Barely. GNOME seems to do its best to hide window titles, so something like a URL bar is probably a better bet. Also, users are already (hopefully) trained to look for an indication in the URL bar that something is secure or insecure. We could also put a short explanation of what is going on in a GtkInfoBar to make it really stand out. I guess the goal is to make the chrome distinctive enough that a user stops to think something is not right, don't enter password when the captive portal helper appears and displays google.com. But that's not even right. Suppose you have a captive portal that wants you to log in via your Google account. It can send you do https://accounts.google.com, and your browser can verify the certificate and show you an indication that the connection is secure. Then you really can safely enter your password. With the current gnome-shell-portal-helper, there is no chrome at all, which means that the captive portal gets to show its own chrome, and it could, for example, make the login window look exactly like Firefox. I bet that even the most sophisticated users lose in that case. I think the UI should look like a real browser except that it should clearly indicate that it's a Log in to wireless network browser in addition to showing a standard URL bar. https://bugzilla.gnome.org/show_bug.cgi?id=749197 FWIW the tech used for GNOME apps that need a web view is WebKitGTK+. Can that provide real chrome? --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 12 Jun 2015, Matthew Miller wrote: Another integration concern: the network config GUI (and ifcfg files, for that matter) let me list specific DNS servers. With this feature, are those used (and if so, how)? If not, is my configuration just silently ignored? I do not know if it is supported currently, but support for that is very trivial. If unbound is found running, issue: unbound-control forward_add . 1.2.3.4 5.6.7.8 I'm not sure whose job that would be. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 09:57 -0400, Paul Wouters wrote: On Fri, 12 Jun 2015, Matthias Clasen wrote: I've just installed dnssec-trigger on rawhide to try this out, and found that it breaks networking on my Workstation. I used to get a network connection on login, now I get a question mark in top bar, and a status icon with obsure menu options appears. Did your networking actually break, or just the notification icon status? Is the unbound service running? Is the dnssec-triggerd service running? I have noticed that the network status icon in the top right has never worked for me in at least a year. It sometimes says ? when I have proper network connectivity and sometimes shows the wifi waves when I do not have network connectivity. I did not realise this might have been due to dnssec-triggerd/unbound. Maybe that is because you play too much with DNSSEC ? :-) It works pretty reliably for me and we don't have a huge influx of 'network status is broken' bugs which we would have if it was as broken as you say... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 10:20 -0400, Matthew Miller wrote: On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote: NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. Another integration concern: the network config GUI (and ifcfg files, for that matter) let me list specific DNS servers. With this feature, are those used (and if so, how)? If not, is my configuration just silently ignored? NM will use those DNS servers as it always has, and with dns=unbound will simply forward them to unbound, which will use your servers as the upstream servers. Basically, any information that NM used to write to resolv.conf will now instead get forwarded to unbound. What unbound wants to do with it is another story, of course, that I'm not an expert on but Thomas/Paul/etc are. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
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. Okay, let's start once again from scratch. All of this was already discussed and we even had a huge meeting around DevConf and FLOCK 2014 about this, so following text will be just a short refresher: The ultimate goal = Make various man-in-the-middle attacks *automatically* detectable - without any user interaction. Especially we want to get rid of dialogs like Site www.gmail.com is using certificate issued for xxx.porn and certificate's validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]. Tools = To achieve this goal we need to do DNSSEC validation on every client machine (ignoring Docker for a moment, see below) and allow applications to use DNS as trusted source of sensitive data (certificate fingerprints, SSH fingerprints, etc.). DNSSEC allows all parties to publish their fingerprints in DNS and gives us a secure way to get the data and to detect that someone prevents us from getting the data. Longer description == http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/ First step: DNSSEC validation = Contemporary networks are full of broken DNS proxies so we need to jump through various hoops to get non-faked DNSSEC data for DNSSEC validation. The goal of this step is to get *cryptographical* proof that the data we received are the same as DNS zone owner published. This includes two sub-problems: a) Hot-spots: Captive portal detection needs to allow user to disable all the security so he can log-in but this needs to be done in a secure and reliable way so an attacker cannot misuse this. b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. All these sub-problems (including VPN handling an so on) are solved by dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda. HERE we need to coordinate with other parties who might want to write into the /etc/resolv.conf file. These include (but might not be limited to): NetworkManager initscripts dhclient libreswan ? resolved connman Option is either to implement all the checks and workarounds in all the projects over and over or to implement all the logic in one place - dnssec-trigger might be such place. Anyone who is going to write to resolv.conf needs to check for captive portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS servers and domains. *Questions:* Guys, what are your plans for handling the situations mentioned above? Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? Second problem: API for applications (this second step is not part of the F23 feature but it is worth discussing) Applications and crypto libraries need an interface to get DNS data which are either 100 % correct or declared as not trusted. False positive (trusted) answers are simply unacceptable because that would allow serious attacks. Imagine that OpenSSH client is verifying server's fingerprint against the value obtained from DNS *instead of asking the user*. If the client accepted a fake response with faked server's fingerprint then everything is doomed. The proposal https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html on glibc mailing list is to extend getaddr API with flag which says 'secure answers only'. This will return an answer only if DNSSEC validation for given answer was successful and the answer was properly signed. The assumption here is that something like dnssec-trigger properly configures local resolver (using the information from DHCP + applying all the necessary workarounds) to do DNSSEC validation locally so we are 100 % sure that the fake answer can be detected. The open question is how to pass the information about security status to all the parties. The mechanism needs to be simple so other resolver libraries like e.g. python-dns can follow the same rules and use the same logic as Glibc. Possible states: a) We are in hot-spot sign-on mode or validating resolver is unavailable for some reason (early boot, resource constraints, Docker container [finally!], and so on): In this case *nothing* can be trusted. Resolver might return faked answers and we have no means to check if declared trustworthiness is correct or not. Again, we need to be 100 % sure from the
Re: F23 System Wide Change: Default Local DNS Resolver
On 06/12/2015 11:10 AM, Petr Spacek wrote: HERE we need to coordinate with other parties who might want to write into the /etc/resolv.conf file. These include (but might not be limited to): NetworkManager initscripts dhclient libreswan ? resolved connman Option is either to implement all the checks and workarounds in all the projects over and over or to implement all the logic in one place - dnssec-trigger might be such place. Anyone who is going to write to resolv.conf needs to check for captive portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS servers and domains. *Questions:* Guys, what are your plans for handling the situations mentioned above? libreswan will not write /etc/resolv.conf is unbound is running. Instead via its _updown script it currently adds the forwarders to unbound and performs the cache flush / requestlist flush. Then it signals NM (which currently then does the same thing - the libreswan specific code can be removed for fedora/rhel when we know the NM version is handling it) Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? If we could have a hotspot logon network container, which will use its own /etc/resolv.conf and its own disposable DNS, I think the host /etc/resolv.conf could be an immutable 127.0.0.1 entry only. Second problem: API for applications (this second step is not part of the F23 feature but it is worth discussing) Applications and crypto libraries need an interface to get DNS data which are either 100 % correct or declared as not trusted. False positive (trusted) answers are simply unacceptable because that would allow serious attacks. Imagine that OpenSSH client is verifying server's fingerprint against the value obtained from DNS *instead of asking the user*. If the client accepted a fake response with faked server's fingerprint then everything is doomed. That is partially solved with a network logon container. Such a container also resolves the problem of every application immediately connecting to the network when a new network is detected, and all of them hitting the hotspot IP redirect and hitting bad certificates. Firefox is somewhat smart about not reloading its tabs these days, but for instance pidgin is terrible and all my XMPP/jabber servers will throw a TLS warning on the screen. The real fix is for these applications to never experience the hotspot login state. The proposal https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html on glibc mailing list is to extend getaddr API with flag which says 'secure answers only'. This will return an answer only if DNSSEC validation for given answer was successful and the answer was properly signed. The assumption here is that something like dnssec-trigger properly configures local resolver (using the information from DHCP + applying all the necessary workarounds) to do DNSSEC validation locally so we are 100 % sure that the fake answer can be detected. The open question is how to pass the information about security status to all the parties. The mechanism needs to be simple so other resolver libraries like e.g. python-dns can follow the same rules and use the same logic as Glibc. This still seems a largely unsolved/unagreed on problem we have had a lot of discussion about. Possible states: a) We are in hot-spot sign-on mode or validating resolver is unavailable for some reason (early boot, resource constraints, Docker container [finally!], and so on): In this case *nothing* can be trusted. Resolver might return faked answers and we have no means to check if declared trustworthiness is correct or not. Again, we need to be 100 % sure from the cryptographical point of view. = Application MUST NOT receive any answer marked as secure/trusted if we are in this mode. the application shouldn't even be exposed to the world while we are in this mode. The world isn't ready yet for them. Additionally, one could extend this concept and say there is a DMZ and internal network on the host, and only very selected few applications get onto the DMZ. The hotspot logon is one such app, another one are the VPN apps. For VPN apps, one could leave only the VPN daemons exposed to the external network, and force all applications to only see the world through the VPN. Without a VPN, the host could decide that once hotspot sign happened, to just bridge or move the DMZ into the internal zone. b) Validating resolver is up, running, properly configured, and the path to the resolver is trusted - it might be running on localhost or we are in Docker container and we trust the host and so on. In this case we trust to the result of validation indicated by AD bit. Application will receive the answer marked as trusted if the resolver tells us to do so by AD bit in the DNS reply. Additionally, these
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek 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. Okay, let's start once again from scratch. All of this was already discussed and we even had a huge meeting around DevConf and FLOCK 2014 about this, so following text will be just a short refresher: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. The ultimate goal = Make various man-in-the-middle attacks *automatically* detectable - without any user interaction. Especially we want to get rid of dialogs like Site www.gmail.com is using certificate issued for xxx.porn and certificate's validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]. Tools = To achieve this goal we need to do DNSSEC validation on every client machine (ignoring Docker for a moment, see below) and allow applications to use DNS as trusted source of sensitive data (certificate fingerprints, SSH fingerprints, etc.). DNSSEC allows all parties to publish their fingerprints in DNS and gives us a secure way to get the data and to detect that someone prevents us from getting the data. Longer description == http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/ First step: DNSSEC validation = Contemporary networks are full of broken DNS proxies so we need to jump through various hoops to get non-faked DNSSEC data for DNSSEC validation. The goal of this step is to get *cryptographical* proof that the data we received are the same as DNS zone owner published. This includes two sub-problems: a) Hot-spots: Captive portal detection needs to allow user to disable all the security so he can log-in but this needs to be done in a secure and reliable way so an attacker cannot misuse this. b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? All these sub-problems (including VPN handling an so on) are solved by dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda. HERE we need to coordinate with other parties who might want to write into the /etc/resolv.conf file. These include (but might not be limited to): NetworkManager initscripts dhclient libreswan ? resolved connman pppd, vpnc, openvpn, etc. should get added to the list since they all have scripts that can potentially write to /etc/resolv.conf. Option is either to implement all the checks and workarounds in all the projects over and over or to implement all the logic in one place - dnssec-trigger might be such place. Anyone who is going to write to resolv.conf needs to check for captive portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS servers and domains. *Questions:* Guys, what are your plans for handling the situations mentioned above? Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? This is the real issue. It sounds like What you're proposing is to make dnssec-trigger into the DNS broker. The previous solutions (resolvconf, NetworkManager, etc) have all failed for various reasons. Touching/changing something so fundamental to the system, as you've probably discovered, can be hard... systemd-resolved might have a chance here, since it's small and pretty simple, but they don't have an external API and don't seem interested in creating one any time soon which severely limits it's usefulness. If this is indeed what you're proposing, then lets have a discussion about dnssec-trigger+unbound in that context, I do have some thoughts to contribute here. The third part of the problem, unrelated to
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote: On 11.06.2015 22:48, Dan Williams 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. NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. Correct, and I personally have no problem with this. NM is quite happy to hand off DNS information wherever it has been told to do so. But this is separate from the connectivity detection/hotspot issue which I think we'll discuss more below. The cases when local (to the network you are connected to) DNS resolver does not support DNSSEC is handled by the logic in dnssec-trigger and dnssec-trigger script. Unbound is always configured in a way that it is able to do DNS resolution and DNSSEC validation. If this can not be done, the user is informed. Right, and that's where most of this discussion lies, I think. 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. If there is such situation, that Unbound fails all DNS lookups, then it is a bug. This is pure theory until you have some real situation. The logic is designed in a way to prevent such situations from ever happen. Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done by putting DHCP provided resolvers into resolv.conf. So in this situation Unbound it not used at all. 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. 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 1.1. Dispatch dispatcher with the network configuration change event. 2. NM updates DNS information NM is not expected to touch resolv.conf in the intended default configuration. My #2 was intended to be the same as your #1.1. I was assuming dns=unbound here. 3. NM waits for some signal from unbound/dnssec-trigger about the trustability of the DNS server If you think NM needs to do some action (as I don't), we don't have problem with notifying NM (if you provide some API). NM may need to do some action for connectivity checking. 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? The only trusted DNS resolver is the local Unbound. The DNS resolver from the network you are connected to is never trusted. It is just used in case it can provide all the necessary information to do the DNSSEC validation. Since using such data we are able to build the chain of trust and verify that the Answer is correct, there is no point in distinguishing if network provided resolver is trusted or not... it is not. This is the reason we do the validation locally. Ok, I should rephrase my question to be clearer. NM's connectivity checking
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 13:00 -0400, Matthew Miller wrote: I hope we can get a design for this which integrates better with GNOME Shell and the existing network icon there. Well we're just not going to ship this in Workstation if it breaks NetworkManager's connectivity checking, nor will we ship anything that displays a system tray icon (that looks like a debugging tool, not something users should ever see). But there's plenty of time left before Fedora 23, and it sounds like several people are trying to fix these things, so hopefully that will all be taken care of and we'll be able to spotlight the local DNS resolver as a major new security feature come release time. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 06/12/2015 12:53 PM, Dan Williams wrote: b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. While I don't actually care, this might well be a sticking point for many people since their DNS information is going to an untrusted (to them) DNS server. Yeah, I tend to trust Fedora, but not everyone will. Can the tunnel be turned off, or the broken servers whitelisted, or is the answer here to just dnf remove dnssec-trigger? The fallbacks are configured in /etc/dnssec-trigger/dnssec-triggerd.conf # Provided by fedoraproject.org, #fedora-admin # It is provided on a best effort basis, with no service guarantee. ssl443: 140.211.169.201 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 140.211.169.201 ssl443: 66.35.62.163 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 66.35.62.163 ssl443: 152.19.134.150 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2 tcp80: 152.19.134.150 ssl443: 2610:28:3090:3001:dead:beef:cafe:fed9 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64 :AA:87:E6:F2 tcp80: 2610:28:3090:3001:dead:beef:cafe:fed9 Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? This is the real issue. It sounds like What you're proposing is to make dnssec-trigger into the DNS broker. The previous solutions (resolvconf, NetworkManager, etc) have all failed for various reasons. Touching/changing something so fundamental to the system, as you've probably discovered, can be hard... But it must be done for security reasons. systemd-resolved might have a chance here, since it's small and pretty simple, but they don't have an external API and don't seem interested in creating one any time soon which severely limits it's usefulness. And last I looked it did not support DNSSEC. I'm also weary about systemd-resolved basically marshalling DNS via DBUS. If this is indeed what you're proposing, then lets have a discussion about dnssec-trigger+unbound in that context, I do have some thoughts to contribute here. I believe we selected dnssec-trigger because it was the UI/daemon that worked. A better native integration into either NM or Gnome would be preferred. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
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
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote: Yeah, we did. From my recollection, most of that focused on the unbound parts and how NM could add the dns=unbound stuff (which Pavel contributed) but less on the NM connectivity checking, becuase Fedora hadn't turned that on by default yet. I'm all fine with dns=unbound, that's not the issue. The issue is more around what happens with NM's connectivity checking, since that's used by quite a few clients, including GNOME Shell. I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. I understand Hotspot sign-on and can go from there, but I can't see it not completely perplexing e.g. my dad. I don't know what Reprobe does (and especially not because there's no context other than the anchor), and Probe Results give some indication that it has to do with DNSSEC — but I think that if our users have to learn what that means and understand all that in order to be secure (or just to browse the web at _any_ level), we're not succeeding. I hope we can get a design for this which integrates better with GNOME Shell and the existing network icon there. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote: On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams d...@redhat.com 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. So it sounds like there are two levels here: 1) connectivity detection and hotspot login using the network-provided DNS servers, which are quite possibly insecure and/or broken 2) once that is all done, handling DNSSEC issues if the network-provided DNS servers are insecure/broken. Which is fine; I'm mostly concerned with #1 at this point because I don't think NetworkManager has much to do with #2 since it already has mechanisms to push the network's DNS servers to whatever wants it (unbound, etc). 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. I was unclear. Here I mean do whatever the config files say to do which is either write resolv.conf, not touch resolv.conf at all
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote: NetworkManager is pure network configuration manager in this scenario. We don't expect nor want NM to handle /etc/resolv.conf. We will only get the current network configuration from it and act upon it. NM configuration will contain dns=unbound. Another integration concern: the network config GUI (and ifcfg files, for that matter) let me list specific DNS servers. With this feature, are those used (and if so, how)? If not, is my configuration just silently ignored? -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 12 Jun 2015, Matthias Clasen wrote: I've just installed dnssec-trigger on rawhide to try this out, and found that it breaks networking on my Workstation. I used to get a network connection on login, now I get a question mark in top bar, and a status icon with obsure menu options appears. Did your networking actually break, or just the notification icon status? Is the unbound service running? Is the dnssec-triggerd service running? I have noticed that the network status icon in the top right has never worked for me in at least a year. It sometimes says ? when I have proper network connectivity and sometimes shows the wifi waves when I do not have network connectivity. I did not realise this might have been due to dnssec-triggerd/unbound. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 12:17 -0500, Dan Williams wrote: 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. Hi. In general, prompts along the lines of do insecure thing [yes] [no] are a big no-no. You should either always do the insecure thing (if it really must be allowed) or never do the insecure thing (preferably), but prompting the user to make a confusing security decision is not OK. In this case I assume always failing the connection is the right thing to do, as to do otherwise would defeat the purpose of this feature. If we could automatically display some very basic troubleshooting steps (call your ISP and tell them xyz), that would be good too. But I presume it's unlikely that every workaround will fail and the user is stuck without DNS? Hopefully that would be rare. If it's not and the user really must be given a choice to allow insecure DNS, then maybe the world just isn't ready for DNSSEC yet -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 12 Jun 2015, Matthew Miller wrote: I personally find the anchor icon very confusing. As a non-expert in this area, it doesn't represent anything which seems relevant to me, and all of the right click menu options, once I figured out to right click, are obscure to me. Agreed. I don't know what Reprobe does (and especially not because there's no context other than the anchor), and Probe Results give some Those are really developer only things and I agree users shouldn't even need to see those. dnssec-trigger continiously keeps probing while in hotspot mode to check when the jailing has been removed and real internet access is available. I hope we can get a design for this which integrates better with GNOME Shell and the existing network icon there. That would be nice indeed. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, Jun 12, 2015 at 10:17 AM, Dan Williams d...@redhat.com wrote: On Fri, 2015-06-12 at 00:48 -0400, Paul Wouters wrote: 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. If you have automatic VPN connection enabled, then I don't really see how a captive portal login can be done fully safely without a container -- the captive portal login should see a route or even interface that should never be visible to anything else. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, Jun 12, 2015 at 10:33 AM, Dan Williams d...@redhat.com wrote: On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote: On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams d...@redhat.com 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. So it sounds like there are two levels here: 1) connectivity detection and hotspot login using the network-provided DNS servers, which are quite possibly insecure and/or broken 2) once that is all done, handling DNSSEC issues if the network-provided DNS servers are insecure/broken. Which is fine; I'm mostly concerned with #1 at this point because I don't think NetworkManager has much to do with #2 since it already has mechanisms to push the network's DNS servers to whatever wants it (unbound, etc). Fair enough. To me, it seems like the awkward interaction is that we sort of have a layering violation. If we think that NM and hotspot login's job is to detect a captive portal and possibly enable a UI to log in and the DNS resolver's job is to never give insecure results, then we need some way to let the portal login UI function without interacting with the DNSSEC-validating DNS server. This might need either special glibc support or some kind of container that can override /etc/resolv.conf just for the purpose of captive portal login. If the ultimate solution ends up involving namespaces, I'd be more than happy to help. I think the *UI* for connectivity indication and portal login certainly is a desktop specific task, because it's part of the network connection user experience. Whether that's GNOME or KDE or LXDE or whatever doesn't matter, but all those environments have preferred ways of interacting with network connections and portal login will need to be part of that. The backend that
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 12 Jun 2015, Andrew Lutomirski wrote: All that makes sense. Thanks. FWIW, I think that a little C program to spin up a namespace that's good enough to point a stateless Firefox instance at a captive portal login with overridden DNS nameserver settings would only be a couple of hundred lines of code. It could even accept a netns to use as part of its input. The only hard part would be convincing Firefox to show an appropriate UI. It wouldn't really have to be Firefox, but getting the browser chrome right to avoid trivial phishing attacks is critical, and all real browsers already do that fairly well, whereas the simple embedded web views (e.g. gnome-shell-portal-helper) get it nearly 100% wrong. dnssec-triggerd can be configured which application to give the url to for hotspot login. Currently: login-command: xdg-open If you write that little C program, I will test it as replacement for xdg-open (which attimes does fail to appear for me, but usually I have firefox open already so I create a new tab and hit 1.2.3.4) We could ship it as part of dnssec-trigger or another package. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
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]
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote: 3. NM waits for some signal from unbound/dnssec-trigger about the trustability of the DNS server If you think NM needs to do some action (as I don't), we don't have problem with notifying NM (if you provide some API). This is your feature, so you are responsible for making sure that it does not break the rest of the OS, not the other way around... I've just installed dnssec-trigger on rawhide to try this out, and found that it breaks networking on my Workstation. I used to get a network connection on login, now I get a question mark in top bar, and a status icon with obsure menu options appears. This is quite a contrast from what the Change page says: Users shouldn't notice this change at all. The OS integration of this feature is clearly not done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Fri, Jun 12, 2015 at 09:57:38AM -0400, Paul Wouters wrote: Did your networking actually break, or just the notification icon status? It will definitely break on F22 without the updated SELinux or SELinux in permissive mode. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
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. 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. 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 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? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams d...@redhat.com 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
Re: F23 System Wide Change: Default Local DNS Resolver
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. 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. 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) 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. 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. 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) 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 11.6.2015 07:39, P J P wrote: Hello Miloslav, On Wednesday, 10 June 2015 8:55 PM, Miloslav Trmač m...@redhat.com wrote: We’ve had earlier conversations about whether the resolver being used (local, remote, container host) is trusted to perform DNSSEC validation. How is this resolved? The Change page AFAICS doesn’t say. Do you e.g. plan to have a configuration file which tells libc/and other applications dealing with resolv.conf directly to know whether the resolver can be trusted for DNSSEC? Or is perhaps the design that any resolver in /etc/resolv.conf is always trusted for DNSSEC, and sysadmins need to ensure that this is true if they use a remote one? Ummn...not any resolver in resolv.conf, but 127.0.0.1 is considered to be trusted. The proposed change is also to ensure that resolv.conf always has only 127.0.0.1 entry in it; And nothing else. Configuration changes to indicate 'trusted' character of a resolver was proposed to upstream glibc, but that is yet to be resolved properly. - https://www.sourceware.org/ml/libc-alpha/2014-11/msg00426.html Let me add that this concept of 'trusted' resolver will be added later when Glibc gets extended API which actually can convey the information. Realistically, in Fedora 23 we will not have the API available because Glibc upstream is quite unresponsive about this. As a result, we are not going to declare anything to be 'trusted' in Fedora 23. For now apps should not make any assumptions about resolver trustworthiness (as they did for decades). -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Hello Miloslav, On Wednesday, 10 June 2015 8:55 PM, Miloslav Trmač m...@redhat.com wrote: We’ve had earlier conversations about whether the resolver being used (local, remote, container host) is trusted to perform DNSSEC validation. How is this resolved? The Change page AFAICS doesn’t say. Do you e.g. plan to have a configuration file which tells libc/and other applications dealing with resolv.conf directly to know whether the resolver can be trusted for DNSSEC? Or is perhaps the design that any resolver in /etc/resolv.conf is always trusted for DNSSEC, and sysadmins need to ensure that this is true if they use a remote one? Ummn...not any resolver in resolv.conf, but 127.0.0.1 is considered to be trusted. The proposed change is also to ensure that resolv.conf always has only 127.0.0.1 entry in it; And nothing else. Configuration changes to indicate 'trusted' character of a resolver was proposed to upstream glibc, but that is yet to be resolved properly. - https://www.sourceware.org/ml/libc-alpha/2014-11/msg00426.html --- Regards -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Hello, = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. We’ve had earlier conversations about whether the resolver being used (local, remote, container host) is trusted to perform DNSSEC validation. How is this resolved? The Change page AFAICS doesn’t say. Do you e.g. plan to have a configuration file which tells libc/and other applications dealing with resolv.conf directly to know whether the resolver can be trusted for DNSSEC? Or is perhaps the design that any resolver in /etc/resolv.conf is always trusted for DNSSEC, and sysadmins need to ensure that this is true if they use a remote one? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Hello Vit, On Tuesday, 9 June 2015 12:22 PM, Vít Ondruch wrote: I hope that I won't need to do this steps manually after F23 installation, otherwise it could be hardly called default. So when there will be available final version which does not need any additional configuration available for testing? As per F23 schedule, it's post 28 Jul 2015 - https://fedoraproject.org/wiki/Releases/23/Schedule --- Regards -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Dne 9.6.2015 v 13:18 P J P napsal(a): Hello Vit, On Tuesday, 9 June 2015 12:22 PM, Vít Ondruch wrote: I hope that I won't need to do this steps manually after F23 installation, otherwise it could be hardly called default. So when there will be available final version which does not need any additional configuration available for testing? As per F23 schedule, it's post 28 Jul 2015 - https://fedoraproject.org/wiki/Releases/23/Schedule That is the latst possible date when it should be definitely available. I can't see any reason why it should not be possible immediately, be it Copr build if you have some reasons not to push it into Rawhide. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Dne 1.6.2015 v 14:03 Jan Kurik napsal(a): = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver The How To Test section now contains a lot of steps such as configure NM, enable/disable service, but when there will be something which I can get working just by something like dnf install localsdnsresolver. I hope that I won't need to do this steps manually after F23 installation, otherwise it could be hardly called default. So when there will be available final version which does not need any additional configuration available for testing? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Tue, 9 Jun 2015, Matthew Miller wrote: One (new!) thing I'm concerned with, now that I've enabled it on my system, is the persistant tray notification. This is... confusing and ugly. Can we (for F23 if possible, and F24 if not) get better GNOME Shell integration here? That's been on the TODO list for years, but it seems the hotspot detection mechanisms are not converging. The DNS interception and the HTTP interception really have to be handled together and an informed 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. Ideally, the dnssec-trigger DNS checks would be merged into the native hotspot testing. 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. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
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. 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! -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Tue, Jun 09, 2015 at 01:23:22PM +0200, Vít Ondruch wrote: As per F23 schedule, it's post 28 Jul 2015 - https://fedoraproject.org/wiki/Releases/23/Schedule That is the latst possible date when it should be definitely available. I can't see any reason why it should not be possible immediately, be it Copr build if you have some reasons not to push it into Rawhide. It shouldn't be pushed into rawhide before FESCo approval. but that's on the docket for tomorrow: https://fedorahosted.org/fesco/ticket/1447 Once approved, and assuming it can just happen seamlessly, yeah, it should happen in rawhide. Unless I'm missing something, rather than adding `dns=unbound` to /etc/NetworkManager/NetworkManager.conf, that line could be added to an /etc/NetworkManager/conf.d/30-dnssec-trigger-unbound.conf file owned by the dnssec-trigger package, right? Additionally, dnssec-trigger would be enabled by default. And that all seems fairly seamless to me — except in cases where it conflicts with an existing configuration. One (new!) thing I'm concerned with, now that I've enabled it on my system, is the persistant tray notification. This is... confusing and ugly. Can we (for F23 if possible, and F24 if not) get better GNOME Shell integration here? 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? -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 3.6.2015 10:58, Reindl Harald wrote: Am 03.06.2015 um 09:14 schrieb Petr Spacek: so with setup a dns cache on each and every machine you fuckup your network because you introduce the same negative TTL caching affecting OSX clients for years now Please let me clarify few things: 1) Negative caching is controlled by zone owner. If you are not happy that OSX/Windows clients cache negative answers for zones your company use - no problem, set SOA minimum field to 1 second and be done with that. bad idea when you maintain public nameservers for some hundret domains just I agree that it is a very bad idea to ignore DNS caching. It was built-in on purpose. because broken clietn software I'm sorry for disappointing you. The behavior I describe is standard for last ~ 20 years 1987 (RFCs 1034/1035/2308). If you don't agree with standard then you cannot use DNS technology as standardized. Here I'm not sure if other Fedora users would also welcome non-standard behavior. If you feel that the standard is broken then *please* continue with discussion on IETF's dnsop mailing list: https://www.ietf.org/mailman/listinfo/dnsop Thank you for understanding. Petr^2 Spacek 2) Even if you have setup with site-wide caching resolvers, the responses from internal zones are cached anyway because all resolvers are not authoritative for all zones you care about (unless you are on a really small network). they are and that don't depend on the network size I.e. if the caching is a problem you have the problem even nowadays. The positive caching is controlled by zone owner, too. If you are worried about stale data on clients, go and lower TTL to 1 second. keep your cynicism for yourself lower a TTL to 1 second is pure stupidity and without broken client software not needed in a network with authoritative nameservers where zone data is also shared with *public nameservers* Lowering TTL should work for all clients, no matter if they have local cache or not, i.e. including Windows/OSX. lowering TTLs to fix stupid client defaults is not a fix Hopefully this shows that problem is not *technically* caused by caching on clients but by inappropriate TTL settings in zones. As a network administrator, you have the power to fix that centrally, without a need to touch every single client sorry, but that is complete nonsense -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Am 03.06.2015 um 09:14 schrieb Petr Spacek: so with setup a dns cache on each and every machine you fuckup your network because you introduce the same negative TTL caching affecting OSX clients for years now Please let me clarify few things: 1) Negative caching is controlled by zone owner. If you are not happy that OSX/Windows clients cache negative answers for zones your company use - no problem, set SOA minimum field to 1 second and be done with that. bad idea when you maintain public nameservers for some hundret domains just because broken clietn software 2) Even if you have setup with site-wide caching resolvers, the responses from internal zones are cached anyway because all resolvers are not authoritative for all zones you care about (unless you are on a really small network). they are and that don't depend on the network size I.e. if the caching is a problem you have the problem even nowadays. The positive caching is controlled by zone owner, too. If you are worried about stale data on clients, go and lower TTL to 1 second. keep your cynicism for yourself lower a TTL to 1 second is pure stupidity and without broken client software not needed in a network with authoritative nameservers where zone data is also shared with *public nameservers* Lowering TTL should work for all clients, no matter if they have local cache or not, i.e. including Windows/OSX. lowering TTLs to fix stupid client defaults is not a fix Hopefully this shows that problem is not *technically* caused by caching on clients but by inappropriate TTL settings in zones. As a network administrator, you have the power to fix that centrally, without a need to touch every single client sorry, but that is complete nonsense signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Am 03.06.2015 um 13:39 schrieb Petr Spacek: On 3.6.2015 10:58, Reindl Harald wrote: Am 03.06.2015 um 09:14 schrieb Petr Spacek: so with setup a dns cache on each and every machine you fuckup your network because you introduce the same negative TTL caching affecting OSX clients for years now Please let me clarify few things: 1) Negative caching is controlled by zone owner. If you are not happy that OSX/Windows clients cache negative answers for zones your company use - no problem, set SOA minimum field to 1 second and be done with that. bad idea when you maintain public nameservers for some hundret domains just I agree that it is a very bad idea to ignore DNS caching. It was built-in on purpose. because broken clietn software I'm sorry for disappointing you. The behavior I describe is standard for last ~ 20 years 1987 (RFCs 1034/1035/2308). If you don't agree with standard then you cannot use DNS technology as standardized. Here I'm not sure if other Fedora users would also welcome non-standard behavior. If you feel that the standard is broken then *please* continue with discussion on IETF's dnsop mailing list: https://www.ietf.org/mailman/listinfo/dnsop come on stop trolling that way because you know exactly what i am talking about by broken client software - the point is that with caching on each and every device you lose the oppotinity clear central caches for whatever reason and make the changes visible on all clients in realtime signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 06/02/2015 08:36 PM, Paul Wouters wrote: On Tue, 2 Jun 2015, Simo Sorce wrote: and just because you have a local resolver firefox won't stop it's behavior It can, w/o a local resolver FF developers will definitely keep caching on their own, with a decent local resolver they can allow themselves to disable their own and go back to rely on the system one, perhaps. I don't think so. Firefox does that to avoid DNS rebinding attacks. It is somewhat questionable whether DNS rebinding vulnerabilities are, in fact, a problem which should be solved at the client side. But Firefox certainly has some caching mechanisms intended to help against that (but I'm not sure how reliable they are in preventing the issue, e.g. if you use a web proxy). -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 1.6.2015 20:58, Reindl Harald wrote: Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski: On Mon, Jun 1, 2015 at 11:02 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III: RSB == Ryan S Brown rya...@redhat.com writes: RSB I disagree; for server cloud deployments it doesn't make sense to RSB duplicate a DNS server on *every* host, and if you care about RSB DNSSEC you likely already run a trusted resolver. I disagree generally in the case of server deployments. Having a local caching resolver is pretty much essential, even though we all know it's just a workaround for glibc. no it is not in case of a serious server setup - period I'm with Jason here. Glibc's resolver is amazingly buggy, and things break randomly and unreproducibly when this happens. A good setup would have a local resolver and glibc would be configured to cache nothing whatsoever. Then, if you need to perform maintenance on the local DNS cache, you can do it by flushing your local resolver rather than trying to figure out how you're going to persuade every running program to tell glibc to flush its cache i never saw glibc caching any dns response, at least on Fedora, new subdomains are working from the moment they are provisioned even if they are tried a few seconds before on Apple clients you need to flush the local cache so with setup a dns cache on each and every machine you fuckup your network because you introduce the same negative TTL caching affecting OSX clients for years now Please let me clarify few things: 1) Negative caching is controlled by zone owner. If you are not happy that OSX/Windows clients cache negative answers for zones your company use - no problem, set SOA minimum field to 1 second and be done with that. Please see http://tools.ietf.org/html/rfc2308 for further details. 2) Even if you have setup with site-wide caching resolvers, the responses from internal zones are cached anyway because all resolvers are not authoritative for all zones you care about (unless you are on a really small network). I.e. if the caching is a problem you have the problem even nowadays. The positive caching is controlled by zone owner, too. If you are worried about stale data on clients, go and lower TTL to 1 second. Lowering TTL should work for all clients, no matter if they have local cache or not, i.e. including Windows/OSX. Hopefully this shows that problem is not *technically* caused by caching on clients but by inappropriate TTL settings in zones. As a network administrator, you have the power to fix that centrally, without a need to touch every single client. I hope this helps. -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 3.6.2015 12:04, Florian Weimer wrote: On 06/02/2015 08:36 PM, Paul Wouters wrote: On Tue, 2 Jun 2015, Simo Sorce wrote: and just because you have a local resolver firefox won't stop it's behavior It can, w/o a local resolver FF developers will definitely keep caching on their own, with a decent local resolver they can allow themselves to disable their own and go back to rely on the system one, perhaps. I don't think so. Firefox does that to avoid DNS rebinding attacks. It is somewhat questionable whether DNS rebinding vulnerabilities are, in fact, a problem which should be solved at the client side. But Oh yes. DNS pinning in browser is just a band-aid and not proper solution. I would argue that DNS rebinding attack is caused by generic lack of ingress filtering on multiple levels. We learned to filter IP packets on firewalls to make sure that packets with internal source addresses come really from interfaces connected to internal networks and the very same principle should apply everywhere... Firefox certainly has some caching mechanisms intended to help against that (but I'm not sure how reliable they are in preventing the issue, e.g. if you use a web proxy). -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Wed, 2015-06-03 at 14:07 +0200, Reindl Harald wrote: Am 03.06.2015 um 14:02 schrieb Petr Spacek: On 3.6.2015 13:45, Reindl Harald wrote: I'm sorry for disappointing you. The behavior I describe is standard for last ~ 20 years 1987 (RFCs 1034/1035/2308). If you don't agree with standard then you cannot use DNS technology as standardized. Here I'm not sure if other Fedora users would also welcome non-standard behavior. If you feel that the standard is broken then *please* continue with discussion on IETF's dnsop mailing list: https://www.ietf.org/mailman/listinfo/dnsop come on stop trolling that way because you know exactly what i am talking about by broken client software - the point is that with caching on each and every device you lose the oppotinity clear central caches for whatever reason and make the changes visible on all clients in realtime You will lose the ability because *you configured the zone with inappropriately long TTL* no, you lose the ability only when each and every device maintains it's own cache while TTL is normally meant for resolvers and you don't need more than *one* trustable and redundant resolver for a whole LAN with that *one* flush on that resolver would lead in the desired result for the whole network and you don't need hacks like dns views for the own LAN with a very low TTL while you don't want that for the rest of the world Reindl can you stop please ? You want to use a standards protocol in a way that it was not designed for. Caching ALL THE WAY DOWN TO CLIENTS is part of the *design* of the protocol. You want to bend it to do things that convenience you and you have KNOBS to do that, the TTL levels. It's really up to you. What is not up to you is telling someone is a troll when they explain to you what a standard says. Go read the fine RFCs now and put up (with proposals in IETF) or shut up please. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 3.6.2015 13:45, Reindl Harald wrote: Am 03.06.2015 um 13:39 schrieb Petr Spacek: On 3.6.2015 10:58, Reindl Harald wrote: Am 03.06.2015 um 09:14 schrieb Petr Spacek: so with setup a dns cache on each and every machine you fuckup your network because you introduce the same negative TTL caching affecting OSX clients for years now Please let me clarify few things: 1) Negative caching is controlled by zone owner. If you are not happy that OSX/Windows clients cache negative answers for zones your company use - no problem, set SOA minimum field to 1 second and be done with that. bad idea when you maintain public nameservers for some hundret domains just I agree that it is a very bad idea to ignore DNS caching. It was built-in on purpose. because broken clietn software I'm sorry for disappointing you. The behavior I describe is standard for last ~ 20 years 1987 (RFCs 1034/1035/2308). If you don't agree with standard then you cannot use DNS technology as standardized. Here I'm not sure if other Fedora users would also welcome non-standard behavior. If you feel that the standard is broken then *please* continue with discussion on IETF's dnsop mailing list: https://www.ietf.org/mailman/listinfo/dnsop come on stop trolling that way because you know exactly what i am talking about by broken client software - the point is that with caching on each and every device you lose the oppotinity clear central caches for whatever reason and make the changes visible on all clients in realtime You will lose the ability because *you configured the zone with inappropriately long TTL*. As usual, it is a trade-off: (performance resiliency) vs. flexibility. It is up to you as an administrator to decide on which side you want to be. Also, feel free to contribute with protocol proposal for DNS cache flushing. dnsop working group already seen few ideas like that and the group is quite open, contributions are welcome! -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Wed, 3 Jun 2015, Petr Spacek wrote: It is somewhat questionable whether DNS rebinding vulnerabilities are, in fact, a problem which should be solved at the client side. But Oh yes. DNS pinning in browser is just a band-aid and not proper solution. I would argue that DNS rebinding attack is caused by generic lack of ingress filtering on multiple levels. I'm not sure we are talking about the same thing here? A DNS rebinding attack works by tricking the browser to resolve something, on which it makes a security decision, eg nohats.ca is 193.110.157.102. The TTL for that would be 0. The browser checks this is a valid src/dst pair. Then it allows this transaction. Another piece of the browser is allowed to run, usually something like flash with its own DNS code, and it has to redo the query since the original TTL was 0. Now the remote DNS server answers with an another IP address that happens to be in your browser's local network. And now the flash plugin is scanning the local network against the actual browser's security policy. Forcing a minimal TTL prevents this, but I think browsers have gone overboard on ignoring bad DNS TTLs for the sake of speed. Note that if you are running unbound as the DNS server, you can configure it to not allow RFC1918 space for all but white listed domains, but this is hard to administrate, and prone to failure when using split DNS. Although ISP caches could surely enable the feature that no RFC1918 may ever appear in public DNS answers. We learned to filter IP packets on firewalls to make sure that packets with internal source addresses come really from interfaces connected to internal networks and the very same principle should apply everywhere... It's hard to do without knowing what kind of network you are on. Can it be trusted or not? If you are at a coffeeshop and starbucks.com resolves to 192.168.1.1, is that trusted or malicious? If you are on a wifi network, should your laptop allow DNS answers for www.redhat.com to be 192.168.1.1 ? It's a hard problem if you try to solve it without whitelists and blacklists, which are in itself not a very good solution. This problem is similar to the network join problem itself. Is this wifi network trusted? Since coffeeshops use WPA with passwords scribbled on the whiteboard, we have no other way than asking the user. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Am 03.06.2015 um 14:02 schrieb Petr Spacek: On 3.6.2015 13:45, Reindl Harald wrote: I'm sorry for disappointing you. The behavior I describe is standard for last ~ 20 years 1987 (RFCs 1034/1035/2308). If you don't agree with standard then you cannot use DNS technology as standardized. Here I'm not sure if other Fedora users would also welcome non-standard behavior. If you feel that the standard is broken then *please* continue with discussion on IETF's dnsop mailing list: https://www.ietf.org/mailman/listinfo/dnsop come on stop trolling that way because you know exactly what i am talking about by broken client software - the point is that with caching on each and every device you lose the oppotinity clear central caches for whatever reason and make the changes visible on all clients in realtime You will lose the ability because *you configured the zone with inappropriately long TTL* no, you lose the ability only when each and every device maintains it's own cache while TTL is normally meant for resolvers and you don't need more than *one* trustable and redundant resolver for a whole LAN with that *one* flush on that resolver would lead in the desired result for the whole network and you don't need hacks like dns views for the own LAN with a very low TTL while you don't want that for the rest of the world signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Wed, 3 Jun 2015, Petr Spacek wrote: ???On 3.6.2015 13:45, Reindl Harald wrote: If you feel that the standard is broken then *please* continue with discussion on IETF's dnsop mailing list: https://www.ietf.org/mailman/listinfo/dnsop come on stop trolling that way because you know exactly what i am talking about by broken client software - the point is that with caching on each and every device you lose the oppotinity clear central caches for whatever reason and make the changes visible on all clients in realtime You will lose the ability because *you configured the zone with inappropriately long TTL*. I have to agree with Petr here. The DNS is specifically designed so that the producer of records can say how long things are allowed to be cached. Chaining caches via forwarders is not against the method of the DNS - it is the core design. Moving the resolving and validation to the end nodes to increase security, and DNS security is something we badly need. Relying on aggregating DNS servers as access control for out-of-band DNS clearing goes against the API contract of a DNS transaction, which comes with a TTL condition. Plus, that assumption has always been broken for browsers already, who keep their own cache. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Le Lun 1 juin 2015 21:25, Reindl Harald a écrit : surely there are many environments beside mine and *that* is why it's not smart to consider a local dns cache on each and every server There are many environments that benefit from a local DNS cache (for example FAI with flacky DNS, people will local cache have perfect service while others wonder why they are disconnected all the time), it can implement DNS features third party DNS miss (so apps don't have to deal with buggy DNSes), and anyone dealing with DNS ops MUST already factor TTLs in since many systems already use DNS caches. The braindamaged thing is to deal with DNS warts localy in all apps instead of using a central system-wide component that can get enough attention to be solid. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 06/01/2015 10:57 PM, Andrew Lutomirski wrote: This is glibc we're talking about, though. Have you tried to get a glibc bug fixed? It's not a pleasant experience. It is possible, but it requires effort. Admittedly, sometimes that effort appears disproportionate to what is being fixed. In this particularly case, only *very* few people are familiar with resolv/, and test coverage for that part is extremely poor. For example, the bug I reported has a candidate patch. That patch isn't applied, and the patch looks like the bug might be a security issue. It's been in that state for months. This is not unusual for glibc. Can you explain why you think it is a security issue? In any case, the impact from accidentally triggering this bug seems more severe. Anyway, even on a LAN, the overhead of a network round trip per cacheable DNS query may be non-negligable for some use cases. A local caching resolver fixes that, too. Right, and it isolates resolvers from the impact of buggy application which enter an infinite loop if a service becomes unavailable (i.e., they do a new DNS lookup for each refused TCP connection). -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Ryan S. Brown rya...@redhat.com wrote: I disagree; for server cloud deployments it doesn't make sense to duplicate a DNS server on *every* host, and if you care about DNSSEC you likely already run a trusted resolver. The trust and management models for Server are fundamentally different from those of Workstation, since servers don't usually get tossed in a backpack and put on potentially-hostile coffee shop wi-fi. They also generally try to run fewer services than a workstation. The datacenter network is generally trusted, and a shared DNSSEC resolver makes way more sense. It may be beneficial from a security PoV to have DNSSEC resolution, but it isn't beneficial to have to patch 1 million copies of unbound if a vuln is discovered instead of just a few shared resolvers for the whole DC. Servers don't only exist in big datacenters where everything is managed by the same team of sysadmins. There are countless servers in homes and small offices around the world, connected to all sorts of more or less trustworthy networks. Some of my current customers have a single server in a collocation facility somewhere. Everything outside of the Ethernet port is managed by other people and shouldn't be trusted any more than necessary. In one of my previous jobs we had servers at multiple geographically separate collocation sites. At each site we'd rent a quarter-height rack with locked doors and install some five or so servers. The network inside the rack was trusted. Beyond the doors was the Internet. Installing redundant dedicated DNS resolvers at each site would have been overkill. The DNS servers we had were authoritative servers for our own domain. If we'd had DNSsec back then it would have made a lot of sense to validate locally on each server. For small offices and home users every little thing that needs to be configured is an additional burden, and chances are that they won't get around to learning how to configure a local validating resolver if it's not there by default. Big data centers, on the other hand, will have automated routines for installing new servers without configuring each one individually. If they choose to delegate the validation to a set of trusted DNS servers, then they can easily configure that in whatever central configuration tool they use, and be done with it. I'll refrain from saying anything about clouds and containers, but for the Server product, like for Workstation, common sense suggests that the default installation should assume as little as possible about its surroundings. It should definitely not assume that there won't ever be any adversaries in the local network when it doesn't know anything about the local network. There should therefore be a local validating DNS resolver by default, and good documentation on how to replace it with trusted external resolvers for those who want to do that. Björn Persson pgpyOjJq4gh_H.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 06/01/2015 09:33 PM, Reindl Harald wrote: Am 01.06.2015 um 21:28 schrieb Andrew Lutomirski: On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown rya...@redhat.com wrote: A local DNS resolver would certainly be a surprise to me. Again, this comes back to the expectation that a server isn't hopping networks or running somewhere un-trusted where there's a high risk of bad actors. It's not just bad actors. Sometimes things break or you need to reconfigure your upstream resolvers. With a local caching resolver, this Just Works (tm). With the status quo, it requires restarting everything WHAT - the opposite is true, Andrew is right, glibc caches the name server *settings* (/etc/resolv.conf contents), but not the responses received. The recommended workaround is to use nscd, but this has issues of its own. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Tue, 2 Jun 2015, Simo Sorce wrote: and just because you have a local resolver firefox won't stop it's behavior It can, w/o a local resolver FF developers will definitely keep caching on their own, with a decent local resolver they can allow themselves to disable their own and go back to rely on the system one, perhaps. I don't think so. Firefox does that to avoid DNS rebinding attacks. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
Am 02.06.2015 um 19:49 schrieb Simo Sorce: On Mon, 2015-06-01 at 23:15 +0200, Reindl Harald wrote: a sane system should be as simple as possible so that *one* human is able to determine what is happening without hire 10 specialists for each layer There is no human able to understand a complex system like modern computers and OSs, it is just an illusion *because* more and more complexity is added with each release and then another layer of complexity is added in the next release to mask the impact on a stripped down Fedora 9 system the output of htop even on a notebook did fit on a screen without scrolling the whole purpose of Linux systems was to have open systems, open means also basically understandable and not just you can grab the source signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 06/02/2015 06:44 PM, Paul Wouters wrote: On Tue, 2 Jun 2015, David Howells wrote: Install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately (e.g. this is stored in the NetworkManager internal state), as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally. How does this interact with dnsmasq which also wants to be the only name server entry in resolv.conf? dnsmasq is not the default entry in /etc/resolv.conf. It can be used with NM, but unbound can be, too. dnsmasq was integrated with NM sooner, since it didn't have DNSSEC support, which made a lot of corner cases and issues basically non-existing. Unbound it relatively simple and single purpose DNS resolver that was designed with DNSSEC in mind from the beginning... in comparison to dnsmasq. dnsmasq is a Swiss knife that is good for simple solutions hacked together with single component (since it supports DHCPv4/6, TFPT and also DNS+DNSSEC). Not well? The problem is dnsmasq is not as feature complete as unbound (and its dnssec implementation is very new). I agree, and as a previous maintainer of dnsmasq, I think unbound is better option. Although dnsmasq has a simple DBus API, it is mostly for DHCP. Also unbound has modular design and easy interface (unbound-control) enabling to reconfigure it dynamically. I think most people end up running dnsmasq because of KVM/libvirtd ? I think those dnsmasq's should be run in dhcp only mode and point to the hosts's unbound. Right. dnsmasq run by libvirtd uses the default configuration WRT resolv.conf. So it uses the servers from resolv.conf for resolution - which will be unbound. There are not conflicts between unbound running as local resolver and dnsmasq instances run by libvirtd. Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
