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.

Name Servers and Trust

The concept of the Domain Name System dates all the way back to its ARPANET days, when a single text file on each ARPANET node – called HOSTS.TXT  – contained the mapping of system names on the ARPANET to their numeric addresses. When you wrote this file yourself, it was easy to be sure it was correct. As the network grew, it became unrealistic to maintain both the central and local copies of this file. By the early 1980s efforts were underway to create a system to automate this process.

The first DNS name server (Berkeley Internet Name Domain Server, or BIND) was written in 1984 by a group of UC Berkeley students, based on RFC 882 and RFC 883. By 1987 the DNS standard had been revised a number of times, resulting in RFC 1034 and RFC 1035, which have largely remained unchanged since then.

The essential structure of DNS is that of a tree-like configuration, with its nodes and leaves subdivided into zones. The DNS root zone is the top-level zone, which consists out of thirteen root server clusters, which form the authoritative DNS root servers. Any newly set up DNS server (e.g. at an ISP or at a company) will end up getting its DNS records from at least one of those servers.

Each further DNS zone adds a further domain to the name system. Each country tends to manage its own domains, with special domains (like .org, .com) which aren’t bound to any specific country managed by a separate entity. When resolving a domain name using DNS, this means starting with the domain name (e.g. .com), then the name (e.g. ‘google’) and finally any sub-domains. This can involve a few trips through DNS zones if the requested data has not been cached already.

DNSSEC: Adding Trust to DNS

Before we get around to encrypting DNS requests, it’s important to be sure that the DNS server we’re talking to can be trusted. The need for this became clear during the 1990s, culminating into the first workable DNS Security Extensions (DNSSEC) standard (RFC 2353) and the revised RFC 4033 (DNSSEC-bis).

A map of the internet in 2006. (Opte project, CC BY 2.5)

DNSSEC works by signing the DNS lookup records with public-key cryptography. The authenticity of a DNS record can thus be verified by the public keys for the DNS root zone, which is the trusted third party in this scenario. Domain owners generate their own keys, which are signed by the zone operator and added to the DNS.

While DNSSEC allows one to be relatively certain that the responses one gets from the DNS resolver is genuine, it does require DNSSEC to be enabled in one’s OS. Unfortunately few OSes implement a DNS service that is more than just ‘DNSSEC-aware’, meaning that they do not actually validate the DNS responses. This means that today one cannot be sure that the DNS responses one receives are genuine.

The Problems with DoH

But let’s imagine that you are using DNSSEC. You’re now ready to encrypt the communication to add a level of privacy to the transaction. There are a number of motivations for keeping one’s DNS queries secret from prying eyes. The more innocent reasons include dodging corporate and ISP filters, preventing tracking of one’s internet habits and so on. More serious motivations include avoiding political persecution for expressing one’s views on the internet. Naturally, encrypting one’s DNS queries prevents people from snooping on those queries, but this ignores most larger security issues with DNS and of course every other communication protocol.

Here, the main contenders are DoT, using TLS, and the proposed DoH, using HTTPS. The most obvious difference between the two is the port they run on: DoT has a dedicated port, TCP 853, whereas DoH mixes in with other HTTPS traffic on port 443. This has the questionable benefit of DNS queries not being distinguishable at all, meaning that it removes options for network operators (private and corporate) to secure their own network, as one of the architects behind DNS, Paul Vixie, pointed out on Twitter last year.

The second main difference is that whereas DoT simply sends DNS queries over a TLS connection, DoH is essentially DNS-over-HTTP-over-TLS, resulting in its own mime Media Type of application/dns-message and significant added complexity. By mixing DoH in with existing protocols, it means that every DNS request and response goes through an HTTPS stack. For embedded applications this is a nightmare scenario, but it is also incompatible with nearly every piece of existing security hardware out there.

DoT has the other advantage that it’s already implemented and has been in use for far longer than DoH, with many parties, including Cloudflare, Google, some national ISPs and standard DNS server software like BIND supporting DoT out of the box. On Android Pie (version 9, for those keeping track) and later, DNS over TLS will be used by default if the selected DNS resolver supports DoT.

Why switch up to DoH just as DoT is finally gaining traction? By having rogue apps like Firefox circumvent the system’s DoT-based DNS and use its own DNS resolver over DoH instead, this makes for a highly opaque security situation. That DNS resolving would move into individual applications, as we see happening now, seems like a massive step backwards. Do you know which DNS resolver each application uses? If it mixes in with TCP port 443 traffic, how would you even know?

Encryption Doesn’t Stop Tracking

Two big parties behind DNS over HTTPS are Cloudflare and Mozilla, the latter of which has produced this cutesy little cartoon in which they try to explain DoH. Not unsurprisingly, in it they completely omit to mention DNSSEC (despite it being referenced as ‘crucial’ in RFC 8484), instead proposing something called Trusted Recursive Resolver (TRR), which seems to basically mean ‘use a trustworthy DNS resolver’, which for Mozilla means ‘Cloudflare’.

Unrelated to DoH, they mention a standard called ‘QNAME minimization’ (RFC 7816) which aims to reduce the amount of non-critical information the DNS resolver sends along to DNS, as covered by this Verisign blog article. As said, this standard has no bearing on DoH and would even work fine without any DNS encryption. Like DNSSEC it’s a further evolution of the DNS standard that improves its security and privacy aspects.

The kicker is in the ‘What isn’t fixed by TRR with DoH?’ section, however. As pointed out by experts on many occasions, encrypting DNS doesn’t prevent tracking. Any subsequent requests to the IP address that one so secretly resolved would still be visible clear as day. Everybody will still know that you’re visiting Facebook.com, or that risky dissident website. No amount of DNS and internet traffic encryption will hide information that is crucial to the functioning of a network like the internet.

The Future Internet is a Single Point of Failure?

Mozilla’s answer to the IP tracking problem is to essentially say that there is no problem, because of the Cloud. As more and more websites and content distribution networks (CDNs) get lumped onto a handful of services (Cloudflare, Azure, AWS, etc.), the meaning of that single IP becomes less and less meaningful, you just have to trust whichever Cloud service you pick to not steal your data, or go down for a day.

This year, there was a massive downtime event on June 24, when a configuration mistake at Verizon led to Cloudflare , Amazon, Linode and many others being unavailable for much of the day. Then on July 2nd of this year Cloudflare as a whole went down for about half an hour, taking down with it many websites that rely on its services.

Coincidentally Microsoft’s Cloud-hosted Office365 also had a multi-hour outage that same day, leaving many of its users stranded and unable to use the service. Meanwhile, on US Labor Day weekend, a power outage over at AWS’ US-East-1 data center led to 1 TB of customer data vanishing as the hardware it was stored on went FUBAR. Clearly there are some issues to be ironed out with this ‘centralizing the internet is good’ message.

What’s Old is New Again

It’s in many ways astounding that in this whole discussion about privacy and tracking there’s no mention of Virtual Private Networks (VPN). These solve the issues of encrypting your data and DNS queries, of hiding your IP address and so much more by simply moving the point where your PC or other internet-enabled device ‘exists’ on the internet. VPNs have been very commonly used by dissidents in authoritarian regimes for decades to get around internet censorship and along with specialized forms such as the Tor network are a crucial element in online freedom.

If one can trust a big commercial entity like Cloudflare in a scheme like DoH, then finding a trustworthy VPN provider who’ll not store or sell your data should be just as easy. Even better, the Opera browser comes with a free, built-in proxy that offers many benefits of VPN.

In summary, one can state that DoH honors its acronym by poorly doing what DoT already does. More focus should be on getting DNSSEC fully implemented everywhere along with DoT and QNAME minimization. And if true privacy by dodging tracking is your goal, then you should be looking at VPNs, especially if you’re a dissident trapped in some authoritarian regime.

The Long History Of Fast Reactors And The Promise Of A Closed Fuel Cycle

The discovery of nuclear fission in the 1930s brought with it first the threat of nuclear annihilation by nuclear weapons in the 1940s, followed by the promise of clean, plentiful power in the 1950s courtesy of nuclear power plants. These would replace other types of thermal plants with one that would produce no exhaust gases, no fly ash and require only occasional refueling using uranium and other fissile fuels that can be found practically everywhere.

The equipment with which nuclear fission was experimentally proven in 1938.

As nuclear reactors popped up ever faster during the 1950s and 1960s, the worry about running out of uranium fuel became ever more present, which led to increased R&D in so-called fast reactors, which in the fast-breeder reactor (FBR) configuration can use uranium fuel significantly more efficiently by using fast neutrons to change (‘breed’) 238U into 239Pu, which can then be mixed with uranium fuel to create (MOX) fuel for slow-neutron reactors, allowing not 1% but up to 60% of the energy in uranium to be used in a once-through cycle.

The boom in uranium supplies discovered during the 1970s mostly put a stop to these R&D efforts, with some nations like France still going through its Rapsodie, Phénix and SuperPhénix designs until recently finally canceling the Generation IV ASTRID demonstrator design after years of trying to get the project off the ground.

This is not the end of fast reactors, however. In this article we’ll look at how these marvels of engineering work and the various fast reactor types in use and under development by nations like Russia, China and India.

Continue reading “The Long History Of Fast Reactors And The Promise Of A Closed Fuel Cycle”

Saying Farewell To Another B-17 And Its Crew

The harsh reality of keeping historical airplanes airworthy and flying is that from time to time one will crash. Thus it was that on October 2nd a Boeing B-17 Flying Fortress crash-landed after technical troubles. Incidentally, this is the very same airplane which we covered only a number of days ago. Painted to look like another B-17 of WWII (Nine-o-Nine, variant B-17G-30-BO), this late-model B-17G-85-DL aircraft wasn’t finished in time to join World War II, but instead spent its 74 years being a flying museum to these amazing airplanes.

Details about the cause of the crash are still scarce, but from radio communication between the crew and tower, it’s understood the B-17 was having having issues with the number 4 engine, which was seen sputtering and smoking by a witness. The airplane’s pilots tried to perform an emergency landing at Bradley International Airport, Connecticut, where it had taken off from only moments ago. Unfortunately the aircraft ran off the runway and struck a building, after which it burst into flames. The NTSB has indicated that they have dispatched a team to investigate the crash, and say that a preliminary report is likely two weeks away.

Of the thirteen people on board, seven died, with the remaining six surviving with injuries. One person on the ground was injured as well. The vintage bomber (civilian registration number N93012) has been all but completely destroyed in the fire, with only a section of the wing and tail remaining recognizable.

We feel terrible about such loss of life and hope the injured make a speedy recovery. The loss of yet another B-17 is also tough to swallow, as this leaves just ten airworthy B-17s. How long until we say farewell to this part of our history, with the final flight of a B-17, or its kin?

(Thanks to Pez for this update)

Using PoE With A Raspberry Pi 3 For About Two Bucks

When the Raspberry Pi 3 Model B+ was announced in March of 2018, one of its new features was the ability to be (more easily) powered via Power-over-Ethernet (PoE), with an official PoE HAT for the low price of just twenty-one USA bucks. The thing also almost worked as intended the first time around. But to some people this just isn’t good enough, resulting in [Albert David] putting out a solution he calls “poor man’s PoE” together for about two bucks.

His solution makes it extra cheap by using so-called passive PoE, which injects a voltage onto the conductors of the network cable being used for PoE, without bothering with any kind of handshake. In general this is considered to be a very reliable (albeit non-standard) form of PoE that works great until something goes up in smoke. It’s also ridiculously cheap, with a PoE injector adapter (RJ-45 plug & 2.1×5.5 mm power jack to RJ-45 jack) going for about 80 cents, and a DC-DC buck converter that can handle the input of 12V for about 50 cents.

The rest of the $2 budget is mostly spent on wiring and heatshrink, resulting in a very compact PoE solution that plugs straight into the PoE header on the Raspberry Pi 3 board, with the buck converter outputs going into the ground and +5V pins on the Raspberry Pi’s GPIO header.

A fancier solution would implement any of the standard PoE protocols to do the work of negotiating a suitable voltage. Maybe this could be the high-tech, $5 solution featuring an MCU and a small PCB?

When Your Car Breaks Down, Simply Hack It Into A Simulator

When [Nishanth]’s Subaru BRZ came to a sudden halt, he was saddened by the wait to get a new engine installed. Fortunately, he was able to cheer himself up by hacking it into a car simulator in the mean time. This would have the added benefit of not being limited to just driving on the Road Atlanta where the unfortunate mishap occurred, but any course available on Forza and similar racing games.

On paper it seemed fairly straight-forward: simply tap into the car’s CAN bus for the steering, throttle, braking and further signals, convert it into something a game console or PC can work with and you’re off to the races. Here the PC setup is definitely the cheapest and easiest, with a single part required: a Macchina M2 Under the Dash kit ($97.50). The XBox required over $200 worth of parts, including the aforementioned Macchina part, an XBox Adaptive Controller and a few other bits and pieces. And a car, naturally.


The Macchina M2 is the part that listens to the CAN traffic via the OBD2 port, converting it into something that resembles a USB HID gamepad. So that’s all a matter of plug’n’play, right? Not so fast. Every car uses their own CAN-based system, with different peripherals and addresses for them. This means that with the Macchina M2 acquired, [Nishanth]’s first task was to reverse-engineer the CAN signals for the car’s controls.

At this point the story is pretty much finished for the PC side of things, but the XBox One console is engineered to only accept official peripherals. The one loop-hole here is the Adaptive Controller, designed for people with disabilities, which allows the use of alternative inputs. This also enables using a car as an XBox One controller, which is an interesting side-effect.

Continue reading “When Your Car Breaks Down, Simply Hack It Into A Simulator”

Tilt Five: A Fresh Take On Augmented Reality Tabletop Gaming

Tilt Five is an Augmented Reality (AR) system developed by Jeri Ellsworth and a group of other engineers that is aimed at tabletop gaming which is now up on Kickstarter. Though it appears to be a quite capable (and affordable at $299) system based on the Kickstarter campaign, the most remarkable thing about it is probably that it has its roots at Valve. Yes, the ones behind the Half Life games and the Steam games store.

Much of the history of the project has been covered by sites, such as this Verge article from 2013. Back then [Jeri Ellsworth] and [Rick Johnson] were working on project CastAR, which back then looked like a contraption glued onto the top of a pair of shades. When Valve chose to go with Virtual Reality instead of AR, project CastAR began its life outside of Valve, with Valve’s [Gabe] giving [Jeri] and [Rick] his blessing to do whatever they wanted with the project.

What the Tilt Five AR system looked like in its CastAR days. (credit: The Verge)

Six years later Tilt Five is the result of the work put in over those years. Looking more like a pair of protective glasses along with a wand controller that has an uncanny resemblance to a gas lighter for candles and BBQs, it promises a virtual world like one has never seen before. Courtesy of integrated HD projectors that are aimed at the retroreflective surface of the game board.

A big limitation of the system is also its primary marketing feature: by marketing it as for tabletop gaming, the fact that the system requires this game board as the projection surface means that the virtual world cannot exist outside the board, but for a tabetop game (like Dungeons and Dragons), that should hardly be an issue. As for the games themselves, they would run on an external system, with the signal piped into the AR system. Game support for the Tilt Five is still fairly limited, but more titles have been announced.

(Thanks, RandyKC)

Dealing With Invasive Species Through Robotics

Throughout its history, humankind’s travels have often brought unwelcome guests along for the ride, and sometimes introduced species into a new environment for a variety of reasons. These so-called invasive species are all too often responsible for widespread devastation in ecosystems, wiping out entire species and disrupting the natural balance. Now researchers are testing the use of robots for population control of these invasive species.

The mosquitofish is the target of current research by NYU Tandon School of Engineering and the University of Western Australia. Originally from parts of the US and Mexico, it was introduced elsewhere for mosquito control, including in Australia. There it has become a massive problem, destroying native species that used to eat mosquitoes. As a result the mosquito problem has actually worsened.

As the main issue with these invasive species is that they do not have any natural predators that might control their numbers, the researchers created robots which mimic the look and motion of natural predators. In the case of the mosquitofish the largemouth bass is its primary predator. The theory was that by exposing the mosquitofish to something that looks and moves just like one of these predator fish, they would exhibit the same kind of stress response.

So far laboratory tests under controlled condition have confirmed these expectations, with the mosquitofish displaying clear signs of stress upon exposure to the robotic largemouth bass. Even better, they displayed decreasing weight and were found to avoid potentially dangerous areas, indicating that instead of focusing on foraging, they were in survival mode. This should limit their environmental impact, including their ability to procreate.

Who knows, before long the surface waters of Australia may be home to the first robotic species of fish.

(Thanks, [Qes])