DNS… and Browsers (Again)

Listening to the security podcasts and those two shills in particular, I hear news of browsers, DNS over HTTPS (DoH), and Business Interests versus the Vox Populi.

The DHCP – DNS – Routing Chain of Trust

DNS is one of those protocols we’ve so well taken for granted that it’s a given that it works — almost a footnote at the application level. A user types a domain name into the browser’s URL bar and the webpage comes back. DNS, of course, is that system behind the scenes that takes the domain name typed and translates it into a routable address — the “you type ‘John Doe’ and the system finds ‘123 Main Street'”-type business. DNS combined with the routing layer just beneath (to include BGP) and the local DHCP service above it and to the side are fundamental infrastructure layers to target if you want to shim your way in to another’s communications. Consider this chain of questions:

  • “Hey! Who’s handling my DNS traffic?” That’s a typical DHCP question.
  • “And where do I send my outbound traffic? (Who is my local gateway?)” Again, DHCP.
  • “Where does tcmlabs.com live?” We ask the DNS service and receive an address.
  • “Who handles email for tcmlabs.com?” Again, a DNS question.
  • “Here’s an email for Joe.” Here, you pass your message, addressed to the tcmlabs.com domain mail server, to the local gateway to initiate routed delivery… Hold on a sec:
  • “Who’s handling that gateway address?” Translated: “Who’s got the local Layer 2 address associated with this IP address for the gateway?” That’s the ARP protocol… Did I forget to mention ARP? Sorry about that.

Anyway, If that description doesn’t inspire security professionals, network engineers, and others, I don’t know what to say. There are entire classes of network attacks based on evil services taking over these functions…

Two Views

Joe Public

You might have gotten your mother on Facebook so she could watch the grandkids, but can you imagine your dad manually setting up DHCP, DNS, & Routing tables to make that happen?

Ridiculous. How does it happen instead? The ISP guy asks, “Where do you want it?” Mom points “There.” The ISP guy drills some holes, runs a wire, powers up their box, and connects the first household computer to the wireless network for free. Done.

Slightly more savvy? Someone drives to Walmart, buys a $50 commodity piece of junk, and connects it to the ISP guy’s wire he left there. The box asks the network, “Hey! Where do I send my outbound traffic and where is my DNS service?” — DHCP requests — and the ISP answers. Outside, they have a dynamically assigned public address, and inside they’re 192.168.1.0/24. Join the wireless network and Facebook is a click away. Done.

Over time, the more paranoid or privacy concerned hear messages about how their ISP is spying on them and selling their data. And who knows? It’s probably true. How does it happen? Well firstly your ISP naturally can see everything you send and they can modify both outbound requests and inbound responses! So, we evolve and encrypt. A ha! Even if the ISP can’t see what they’re sending to Facebook, their DNS service realizes that they typed “facebo0k.com” when it looked up the address for them! How to fight back?

For your general home user, there is nothing in particular that enforces your using the DNS service that your ISP service suggests (in that DHCP exchange), and there’s nothing in particular that enforces a network client to use the DNS service suggested by the Walmart plastic! A savvy user with administrative privileges (which is about anyone for the later half) can manually set his box’s preferred DNS servers. Now, instead of asking locally and having that relayed to the ISP, you can go directly to Google and ask them! [Ok, you can point to lots of places besides Google, but you get the gist.]

But can’t the ISP still see the DNS requests? Even intercept and tamper with the requests and responses? Typically, yes — they can indeed! And they still know what grandma’s up to and can sell her data! Curses!

Alternatives?

Well one of the more popular recent pushes has been commercial VPN services. Every clown is selling them as snake oil cure-alls, and it resonates with folks with these concerns. The idea? ALL of our outbound traffic runs through an encrypted tunnel and pops out somewhere else — network ventriloquism. If the service is smart, all of your parents’ DNS queries also travel through that tunnel and are handled by some other DNS service… which can gather information on your queries and sell the data. Of course, your ISP may see your initial VPN connection, particularly if you use DNS to find the address. Do you believe in Net Neutrality? We’ll see how that goes over time.

Is there any recourse?

Thank you for asking! Your mom’s mostly living in her browser, yes? Well, maybe Candy Crush, too, but mostly the browser. And her browser is where most of those DNS lookups are coming from, right? I mean, there is certainly that first lookup for the casserole recipie, and once she visits that site there is the barrage of web framework lookups, style sheet pulls, the CDN addresses for all of the streaming nonsense, and all of the different tracking and ad service addresses — all generally DNS queries. (Seriously, you might not believe it if you didn’t see the logs for yourself.)

The browser, of course, is aware of each of those links it needs to fetch for your personal entertainment, bringing you all those flashy and loud ads everywhere on the page… Thought experiment: What if the browser itself decided not to use your locally configured DNS services, but instead piped the queries back to itself for handling? Hell, what if happened inside an encrypted protocol defying inspection, and what if was comparatively fast that you’d want to name it QUIC? No? Ok — how about just through a tunnel provided by the venerable HTTPS. (We do all love that lock on the browser bar, right?)

This is DNS over HTTPS. For better or worse, it is fundamentally a service bypass. After all, who will block HTTPS?

Joe Business

Business will, that’s who.

Well, not block it, per se, but certainly inspect it. And even that’s tedious and more troublesome over time as controls evolve to ensure that each endpoint in the conversation knows for certain that it is talking to the right entity — such as with certificate pinning and similar.

Screw business! Right? Well, funny thing… people also don’t want their personal identifying information leaked, their financial information lost, their passwords exposed, their health data to escape, … People also don’t want their kids to be phished or to be exposed to explicit content. The first-level defenses against these types of problems often involve peaking inside HTTPS tunnels to make sure no unauthorized data is finding its way outside the network, and DNS request inspection to see where your crew is going and to block potentially bad sites as the crew clicks those links or types in their NSFW URLs. [Consder the “Pi Hole” project enjoyed by household tinkerers everywhere.]

Additionally, corporate networks have deeper layers of security that have DNS as a foundation — for instance, Active Directory Kerberos realms and server PKI solutions often rely on DNS — and they may employ more complex technologies such as DNSSEC to ensure that you are talking to an authorized DNS server with authoritative organizational information. Additionally, corporate networks may actively hunt for rogue DHCP and DNS services to avoid man-in-the-middle exploits, and they may intercept overt DNS queries to unauthorized DNS servers, blocking them outright or handling the requests itself.

The takeaway? Business has a strong interest both in controlled DNS deployments and even in HTTPS inspection.

Conflict.

So what happens when the web browser has the ability to bypass corporate policies? Does the One Browser to Rule Them All(TM) work to secure your parents or your business?

Just kidding — the browsers are not working for you — not for you personally and not for your business.

In spite of the hype — even my own — security is a dispassionate business and the technologies all have their good sides and bad. As always, consider the brower’s self-interests — not their marketing — in having a place inside your network and having access to all of your users’ browsing data. Stay on top of the recent trends in web browser development and periodically reassess the use of web browsers in your enterprise. Register the security risks, have your team decide for themselves how large the problem is, then mitigate if appropriate.

As for that business of monitoring trends? Discernment through the hype? Dispassionate assessment? Evaluation of risks? If that’s not your bailiwick or if you need that clear set of eyes, contact us.