#173 Enable the most secure browser experience out of the box for our end users.
Closed: Won't fix 3 years ago by johannbg. Opened 3 years ago by johannbg.

Given that we have ( finally ) enabled systemd-resolved by default for F33 we should consider enabling DoT/DNSsec and encrypted SNI in Firefox on F33 to deliver the most secure out of the box browsing experience for our desktop end users and pass cloudflares browser security test [1].

To do so the following steps are required for F31/F32

systemctl stop NetworkManager
rm -rf /etc/resolv.conf
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
mkdir -p /etc/systemd/resolved.conf.d/
cat > /etc/systemd/resolved.conf.d/10-cloudflare.conf << 'EOF'
[Resolve]
DNS=1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
DNSOverTLS=yes
DNSSEC=yes
FallbackDNS=8.8.8.8 9.9.9.9 2001:4860:4860::8888 2620:fe::fe
EOF
systemctl enable --now systemd-resolved
systemctl start NetworkManager

In Firefox
about:config --> network.security.esni.enabled change to True

For F33 it should be a simply a matter of enabling encrypted SNI in Firefox ( bz.rh 1861938 )
and creating the /etc/systemd/resolved.conf.d/ drop in directory and place a secure DNS configuration snippet like the above ( 10-cloudflare.conf ) with whatever defaults people agree on.

Sample configuration files.

10-cloudflare.conf
[Resolve]
DNS=1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
DNSOverTLS=yes
DNSSEC=yes
FallbackDNS=8.8.8.8 9.9.9.9 2001:4860:4860::8888 2620:fe::fe

20-google.conf
[Resolve]
DNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
DNSOverTLS=yes
DNSSEC=yes
FallbackDNS=1.1.1.1 9.9.9.9 2606:4700:4700::1111 2620:fe::fe

30-quad9.conf
[Resolve]
DNS=9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9
DNSOverTLS=yes
DNSSEC=yes
FallbackDNS=1.1.1.1 8.8.8.8 2606:4700:4700::1111 2001:4860:4860::8888

Arguably browser security is of the utmost importances so an exception should be made to allow this change to be made in F33 ( as opposed to delay it to F34 ) or we should atleast I think ship it on the live's if possible.

  1. https://www.cloudflare.com/ssl/encrypted-sni/

Probably more accurate term would be "enable secure lookup by default" but it does not sell as well as "Most secure browser experience" encase marketing would want to highlight this in the release notes.

Hi @stransky, do you have an opinion on this? I understand that currently our Firefox package prefers to trust the user's ISP for DNS, rather than using Cloudflare servers like upstream Firefox does.

Hi @stransky, do you have an opinion on this? I understand that currently our Firefox package prefers to trust the user's ISP for DNS, rather than using Cloudflare servers like upstream Firefox does.

Yes, we disabled DNS over HTTPS by default for Fedora.
Franky I'm not expert in this area so I don't have a strong opinion here.

DNS over TLS doesn't work in resolved: https://github.com/systemd/systemd/issues/16531

Honestly, I would have preferred us using dnsmasq, given the number of gotchas in resolved's implementation of DNS and the prevalent usage of dnsmasq for CRC and virtualization...

Regardless, none of the proposed enhancements work with resolved properly right now, and so I don't want to enable them. DNS over HTTPS is disabled because it breaks with VPNs.

DNS over TLS doesn't work in resolved: https://github.com/systemd/systemd/issues/16531

Just because you found a bug reported upstream does not mean it's not working I'm using the posted configuration myself ( I eat my own dog food ) and they work just fine on F32.

Honestly, I would have preferred us using dnsmasq, given the number of gotchas in resolved's implementation of DNS and the prevalent usage of dnsmasq for CRC and virtualization...

That makes no sense systemd-resolved is approve F33 feature.

Regardless, none of the proposed enhancements work with resolved properly right now, and so I don't want to enable them. DNS over HTTPS is disabled because it breaks with VPNs.

Usually people that criticize things for not working should actually try it out for themselves which is why I posted those directions so people could then file bugs and or provide constructive criticism based on their own result.

Firefox upstream has had DoH enabled since February this year [1] and if it somehow breaks VPN setup those users can just disable it.

  1. https://blog.mozilla.org/blog/2020/02/25/firefox-continues-push-to-bring-dns-over-https-by-default-for-us-users/

If we were going to override the Firefox package maintainers -- and I don't see any strong reason to do so -- then my vote would be for Firefox to use system DNS settings, and for us to figure out how to secure system DNS rather than doing something special just for Firefox. That means no DNS over HTTPS, because systemd has no plans to support it. Now, we are tentatively planning to enable DNS over TLS in resolved by default for F34. I think it would be worth considering automatically falling back to Cloudflare DNS if the user's ISP doesn't support DNS over TLS. But that would require upstream work in systemd to not interfere with split DNS (since if you are using split DNS, then splitting properly is more important than DNS over TLS). And it's probably a bit outside the usual focus of the Working Group. So my proposal is to bounce this over to the systemd developers to figure out.

As for ECH (formerly ESNI), that's completely unrelated and application-specific. It's for Firefox developers to decide. If the preference is disabled by default, I assume it's for good reason, probably because standards are currently rapidly evolving. I presume Firefox will enable this soon, and I'm not sure why the Working Group should second-guess their decision on when to do so.

Proposal: close this issue, defer to systemd on DNS and to Firefox on ECH (formerly ESNI).

Proposal: close this issue, defer to systemd on DNS and to Firefox on ECH (formerly ESNI).

+1

Proposal: close this issue, defer to systemd on DNS and to Firefox on ECH (formerly ESNI).

+1

I was unaware that someone was tentatively planning to enable DNS over TLS in resolved by default for F34 which could have just as well from my pov be done at the same time as resolved got accepted and could have been mentioned at the beginning that was the plan and this issue be closed.

Given that the idea is going against upstream ( Firefox ) of having DoH enabled while at the same time making the argument that the working group should not be second-guess upstream decision sounds not very logical to me.

In anycase the former seems to have been planned to be worked on by someone that had apparently not even bother to write a change proposal about doing so ( atleast I did not find one when I was planning on writing a proposal for this which is perfectly fine, It just save me from having to do any of the work ) and the latter of my proposal would have simply eliminated the step for the end user having to go to "about:config" in firefox if the end user had chosen to enable DoH in firefox which apparently should not be done because that specific issue is considered going against the wishes of upstream or downstream firefox maintainers while others decisions that do exactly that apparently do not hence I will simply close this issues since there is no purpose of keeping it open or voted upon.

Metadata Update from @johannbg:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

3 years ago

I was unaware that someone was tentatively planning to enable DNS over TLS in resolved by default for F34 which could have just as well from my pov be done at the same time as resolved got accepted and could have been mentioned at the beginning that was the plan and this issue be closed.

The reason for deferring DoT to F34 was so that we could do a two-step rollout: first switch to systemd-resolved in F33, allow some time for systemd package maintainers to deal with inevitable fallout, and then enable DoT in F34. It's just a bit easier for package maintainers than landing two big changes at the same time.

Given that the idea is going against upstream ( Firefox ) of having DoH enabled while at the same time making the argument that the working group should not be second-guess upstream decision sounds not very logical to me.

So the difference between DNS and ECH is that DNS is an OS feature that is generally expected to be standard and consistent across the entire distribution, whereas ECH is a TLS library feature. Changing Firefox's DNS settings to match the rest of Fedora can be viewed as good system integration, whereas there's nothing at all Fedora-specific about ECH.

In anycase the former seems to have been planned to be worked on by someone that had apparently not even bother to write a change proposal about doing so ( atleast I did not find one when I was planning on writing a proposal for this which is perfectly fine, It just save me from having to do any of the work )

There's not yet a formal change proposal for DoT enablement though. If you were planning to write one anyway, it would actually be very helpful if you want to prepare one! Implementation should be very simple as we just need to build systemd with -Ddefault-dns-over-tls=opportunistic. (Alternatively, if someone wants to implement fallback to Cloudflare, then we could use -Ddefault-dns-over-tls=true to prevent downgrade attacks: the worst an attacker could do to you is cause you to fallback to Cloudflare DNS.)

There's not yet a formal change proposal for DoT enablement though. If you were planning to write one anyway, it would actually be very helpful if you want to prepare one! Implementation should be very simple as we just need to build systemd with -Ddefault-dns-over-tls=opportunistic. (Alternatively, if someone wants to implement fallback to Cloudflare, then we could use -Ddefault-dns-over-tls=true to prevent downgrade attacks: the worst an attacker could do to you is cause you to fallback to Cloudflare DNS.)

Quite frankly I was expecting it's to late for F33 and we need a formal change proposal ( but hoping for the former ) as in it being a similar situation as timesyncd discussion was ( needing a formal proposal ) which I kinda had inadvertently signed up for doing + finishing the systemd timer stuff ( depending on FPG ) and throw hot potatos like IWD in the mix and get rid of /etc/sysconfig ( which should have been done prior to RHEL8 ) maybe as well ( it's less work for me if I'm already crawling the core/baseOS layer to do as much work as needed on the components I'm looking at instead of doing multiple iterations )

That said it's best that those that have already discussed and planned a feature proposal will also be the one(s) that run it which apparently is the case here. Something has be decided by someone(s) who have a certain vision how things should be done and implemented in the distribution hence it's best that or those persons do it and fix whatever fallout comes from it and every component it touches. ( I actually bother to go through every component and fix what I can so I dont put unnecessary burden on packaging maintainers while more often than not a group of people make a feature in which it's expected that the package maintainers actually do all the leg work to make that feature come true. )

I would not try to do any of this for F33. Rawhide branches next week, so now is the perfect time to start with F34 change proposals for DoT (and timesyncd) as far as I'm concerned. No need to wait five months until the deadline.

I would think that desktop would want to remove
at
( been replaced with for example systemd-run --on-active="3h 30m" /bin/touch /tmp/foo )
crontabs ( times )
cronie-anacron ( timers )
cronie ( timers )
from their lives and editions but could this could be considered a system wide change just like timesyncd could.

iwd ofcourse is a hotter topic ( I would say iwd+networkd is the cross distro inevitable future ) and given my limited testing on iwd it already gave me better user experience than wpa_supplicant ( faster connection ) hence I would think Gnome/KDE would be eager to switch to it ( might be some outstanding NM bugs upstream and maybe some race connection which probably can be resolved with proper ordering in type units )

/etc/sysconfig is just a relic that contains useless junk but affects probably ca <50 components or so which is not much but definitely is a system wide change which requires probably a change to FPG as well.

I would think that desktop would want to remove
at
( been replaced with for example systemd-run --on-active="3h 30m" /bin/touch /tmp/foo )
crontabs ( times )
cronie-anacron ( timers )
cronie ( timers )
from their lives and editions but could this could be considered a system wide change just like timesyncd could.

We don't need a change proposal to remove packages without replacement. We can handle it in the Workstation WG if you report a separate issue for it.

iwd ofcourse is a hotter topic ( I would say iwd+networkd is the cross distro inevitable future ) and given my limited testing on iwd it already gave me better user experience than wpa_supplicant ( faster connection ) hence I would think Gnome/KDE would be eager to switch to it ( might be some outstanding NM bugs upstream and maybe some race connection which probably can be resolved with proper ordering in type units )

I think we could do this if NetworkManager developers agree everything is ready. Again, that would need a separate Workstation issue tracker. This one will also need to go through the change proposal process.

/etc/sysconfig is just a relic that contains useless junk but affects probably ca <50 components or so which is not much but definitely is a system wide change which requires probably a change to FPG as well.

That one seems outside the scope of Workstation WG. I would go through the normal change proposal process for this.

Login to comment on this ticket.

Metadata