Think You Know CURL? Care To Prove It?

Do you happen to remember a browser-based game “You Can’t JavaScript Under Pressure”? It presented coding tasks of ever-increasing difficulty and challenged the player to complete them as quickly as possible. Inspired by that game, [Ben Cox] re-implemented it as You Can’t cURL Under Pressure!

In it, the user is challenged in their knowledge of how to use the ubiquitous curl in a variety of different ways. Perhaps this doesn’t sound terribly daunting, especially if your knowledge of curl is limited to knowing it is a command-line tool to fetch something from a web server. But curl has a staggering number of features. The man page is over 4500 lines in length. The software’s main site offers a (free) 250+ page guide on how to use curl and libcurl. Reflecting on this is exactly what led [Ben] to create his challenge.

It’s a wonderful piece of work, but things get really interesting once [Ben] starts talking about the infrastructure behind it all. At its core the game works by giving the user a problem and a virtual machine, and catching outgoing HTTP calls to see whether they look correct. If the outgoing HTTP call is the right solution for the problem, terminate the current VM and start up the next one with the next problem. He’s put a lot of work into getting suitable VMs up and running quickly, securely, and properly isolated. The code can be found on the project’s GitHub repository for those who want a closer look.

But that’s not all. [Ben] says that in the past he’s had a bad habit of presenting interactive features in his blog posts that can’t keep up with sudden demand. So to address that, the system auto-scales as needed with a small Linux cluster; small brick-sized PCs are started and shut down automatically to meet demand. Hey, the only thing cooler than a functioning cluster is a cluster doing an actual job, like this one that detects NSFW images.

DNS-over-HTTPS Is The Wrong Partial Solution

Openness has been one of the defining characteristics of the Internet for as long as it has existed, with much of the traffic today still passed without any form of encryption. Most requests for HTML pages and associated content are in plain text, and the responses are returned in the same way, even though HTTPS has been around since 1994.

But sometimes there’s a need for security and/or privacy. While the encryption of internet traffic has become more widespread for online banking, shopping, the privacy-preserving aspect of many internet protocols hasn’t kept pace. In particular, when you look up a website’s IP address by hostname, the DNS request is almost always transmitted in plain text, allowing all the computers and ISPs along the way to determine what website you were browsing, even if you use HTTPS once the connection is made.

The idea of also encrypting DNS requests isn’t exactly new, with the first attempts starting in the early 2000s, in the form of DNSCrypt, DNS over TLS (DoT), and others. Mozilla, Google, and a few other large internet companies are pushing a new method to encrypt DNS requests: DNS over HTTPS (DoH).

DoH not only encrypts the DNS request, but it also serves it to a “normal” web server rather than a DNS server, making the DNS request traffic essentially indistinguishable from normal HTTPS. This is a double-edged sword. While it protects the DNS request itself, just as DNSCrypt or DoT do, it also makes it impossible for the folks in charge of security at large firms to monitor DNS spoofing and it moves the responsibility for a critical networking function from the operating system into an application. It also doesn’t do anything to hide the IP address of the website that you just looked up — you still go to visit it, after all.

And in comparison to DoT, DoH centralizes information about your browsing in a few companies: at the moment Cloudflare, who says they will throw your data away within 24 hours, and Google, who seems intent on retaining and monetizing every detail about everything you’ve ever thought about doing.

DNS and privacy are important topics, so we’re going to dig into the details here. Continue reading “DNS-over-HTTPS Is The Wrong Partial Solution”