Open ghost opened 7 years ago
I don't think we should be trusting the confidentiality of a clearnet DNS lookup regardless of server choice. I think https://github.com/freedomofpress/securedrop/issues/1204 is the way to go here. If we were in addition to route Postfix over Tor on the monitor server, then we'd be able to move to enforcing that all traffic goes over Tor via IPTables rules.
This has not been high on our priority list because our instances are generally public and the DNS lookups they do are generally just for apt repos or smtp servers.
I don't think we should be trusting the confidentiality of a clearnet DNS lookup regardless of server choice
I also dislike relying on 8.8.8.8
however I don't think we should add additional complexity to the install (which is where I assume we would have to set this, in the ansible playbook). I agree with @fowlslegs' statement above
Relevant research on enhancing website fingerprinting attacks with monitored DNS requests: https://freedom-to-tinker.com/2016/09/29/the-effect-of-dns-on-tors-anonymity/. Specifically calls out Google's open DNS resolver (8.8.8.8
) as a potential locus of attack.
Instead of suggesting to use 8.8.8.8
To be clear: we do not suggest that people prefer Google's DNS resolvers. The relevant section of the SecureDrop documentation says "use your preferred DNS servers," and suggests Google's DNS resolvers as a reasonable fallback option.
In general, I think there is only so much we can do here. Given SecureDrop's decentralized architecture, at a certain point SecureDrop administrators simply have to be responsible for the reliable and secure configuration of the upstream network.
There have been BGP attacks and route leaks on 8.8.8.8, most significantly back in 2014. Sometimes they happen without detection. Also just last week with Amazon Route53 ¹ ²!
In the Gitter dev channel today I suggested DNS-over-HTTPS (which I've been using personally for resolution for a few months), though I previously outlined a Tor-based approach which could also work here. This will be an IETF RFC in short order. I recently did a production install on virtual guests while running a packet capture on the interfaces and then analyzed it in Wireshark. Indeed, the lookups to various *.freedom.press repositories were the main thing that stood out like a sore thumb. It stands to reason, along the lines of #1204, that if you can catch these resolutions on the wire then you've got the IP addresses and a rough geographical location of where instances are installed; by virtue of ASN ownership and IP reputation databases it could even leak that a specific organization is involved with SecureDrop if perhaps they don't yet want that to be public.
DoH can be set up with Cloudflare and their 1.1.1.1 resolver (which I'd prefer), or we could also go with dnscrypt-proxy. The best part is it doesn't require any changes to the firewall or iptables rules, since port 443 out is already allowed. I did some testing on my own and the latency difference was negligible, in some cases DoH was even faster than DNS over UDP! That said, I think the Xenial upgrade (#3204) would help here too, because systemd-resolved can help with caching and performing DNSSEC validation. You really want to have strict DNSSEC validation on the servers as part of the whole picture IMO.
I don't think this is particularly critical or pressing, yet the implementation is not that difficult, and it can only benefit and serve the defense-in-depth security model. So I wonder if there should be a dedicated issue for encrypting outbound DNS requests. I'd be happy to help present a PoC/MVP.
This sounds like the scope of the ticket should change. I propose the new goal should be roughly implement encrypted DNS lookups
I like the idea of using Wobscale DNS, especially since its server software is named after my fave Adventure Time character: https://github.com/wobscale/pepbut.
Instead of suggesting to use 8.8.8.8, it would be good to propose alternative services that do not have a past known history of silently sharing their customer information with government agencies: