Boffins: SOPA breaks DNSSEC, and won’t work anyway

Putting a man-in-the-middle into an end-to-end protocol is dumb


It isn’t actually news as such: while the DoE’s own Sandia Labs has warned that the notorious Stop Online Piracy Act is a threat to the deployment of secure DNS – DNSSEC to its friends – the fragility of the protocol has been discussed for ages.

The problem is this: an end-to-end protocol is the simplest way to ensure that a browsing session isn’t hijacked along the way by a fake DNS record. Sandia’s letter is, in that sense, merely reiterating what’s already known.

DNSSEC proposes just such an end-to-end protocol. In today’s insecure world, the ordinary end user has very little opportunity to verify that foo.bar really is 192.168.0.10 rather than 192.168.1.10* – which opens the way to DNS hijacking and makes DNSSEC necessary.

The secured version of DNS performs the same basic function of DNS: it’s still a distributed, queryable database that allows humans to put http://www.theregister.com/ into their browser bar, and get directed to 92.52.96.89 to actually get the content. But it mandates that the domain record used for that resolution is cryptographically signed.

As this paper, cited by Sandia, puts it:

“When implemented end-to-end between authoritative nameservers and requesting applications, DNSSEC prevents man-in-the-middle attacks on DNS queries by allowing for provable authenticity of DNS records and provable inauthenticity of forged data. This secure authentication is critical for combatting the distribution of malware and other problematic Internet behavior.

"Authentication flaws, including in the DNS, expose personal information, credit card data, e-mails, documents, stock data, and other sensitive information, and represent one of the primary techniques by which hackers break into and harm American assets.”

The paper was published in May 2011, in response to a different piece of mandated DNS poisoning stupidity, and is entitled Security and Other Technical Concerns Raised by the DNS Filtering Requirements in the PROTECT IP Bill.

“By mandating redirection, PROTECT IP would require and legitimize the very behavior DNSSEC is designed to detect and suppress,” the paper states. “[A] DNSSEC-enabled browser or other application cannot accept an unsigned response; doing so would defeat the purpose of secure DNS. Consistent with DNSSEC, the nameserver charged with retrieving responses to a user’s DNSSEC queries cannot sign any alternate response in any manner that would enable it to validate a query.”

(It’s worth noting that this latter statement only holds true in a world that’s completely adopted DNSSEC; as Sandia points out, when the majority of assets are still unsigned, browsers will still accept unsigned responses.)

In other words, the fools sockpuppets legislators proposing SOPA’s DNS-interference mechanism have done so when the impact of their thought-bubble was already known.

Moreover, as was pointed out to The Register by Australian Internet luminary Geoff Huston, DNSSEC is designed such that if a fake record is returned – for example, if a US court orders that infringing-site.com returns any address other than the authoritative record – it’s detectable.

“The NXDOMAIN response is a visible fake response in a DNSSEC world. And if you chose to block by non-response, then the DNSSEC NSEC records will again show that this is a lie,” he told us in an e-mail.

Even worse, Huston said, legislation like SOPA could encourage the formation of “darknet” alternative DNSs.

“This will not switch off the content, but will provide impetus for the formation of ‘alternate’ DNS worlds which include the blocked domain names,” he wrote.

“To what extent these alternative worlds will then be populated by ‘fake’ banks, ‘fake’ governments and all other kinds of attempts at trickery is an open question, but it is unlikely that the darker alternate DNS world will be any better than what we have today. So in effect, they argue, these attempts to suppress bad content through mucking around with the DNS encourages other forms of mucking around with the DNS, and that’s not a good thing.”

Nor will the measures proposed in SOPA actually block the content, since users will still be able to locate the “banned” resource directly using the IP address, by running a local resolver, using a foreign resolver, or by editing their hosts file.

As Sandia states, “Even non-technical users could learn to bypass filtering provisions.” ®

*Yes, I know 192.168.nnn.nnn is reserved. It’s an example. ®


Other stories you might like

  • Pentester pops open Tesla Model 3 using low-cost Bluetooth module
    Anything that uses proximity-based BLE is vulnerable, claim researchers

    Tesla Model 3 and Y owners, beware: the passive entry feature on your vehicle could potentially be hoodwinked by a relay attack, leading to the theft of the flash motor.

    Discovered and demonstrated by researchers at NCC Group, the technique involves relaying the Bluetooth Low Energy (BLE) signals from a smartphone that has been paired with a Tesla back to the vehicle. Far from simply unlocking the door, this hack lets a miscreant start the car and drive away, too.

    Essentially, what happens is this: the paired smartphone should be physically close by the Tesla to unlock it. NCC's technique involves one gadget near the paired phone, and another gadget near the car. The phone-side gadget relays signals from the phone to the car-side gadget, which forwards them to the vehicle to unlock and start it. This shouldn't normally happen because the phone and car are so far apart. The car has a defense mechanism – based on measuring transmission latency to detect that a paired device is too far away – that ideally prevents relayed signals from working, though this can be defeated by simply cutting the latency of the relay process.

    Continue reading
  • Google assuring open-source code to secure software supply chains
    Java and Python packages are the first on the list

    Google has a plan — and a new product plus a partnership with developer-focused security shop Snyk — that attempts to make it easier for enterprises to secure their open source software dependencies.

    The new service, announced today at the Google Cloud Security Summit, is called Assured Open Source Software. We're told it will initially focus on some Java and Python packages that Google's own developers prioritize in their workflows. 

    These two programming languages have "particularly high-risk profiles," Google Cloud Cloud VP and GM Sunil Potti said in response to The Register's questions. "Remember Log4j?" Yes, quite vividly.

    Continue reading
  • Rocket Lab is taking NASA's CAPSTONE to the Moon
    Mission to lunar orbit is further than any Photon satellite bus has gone before

    Rocket Lab has taken delivery of NASA's CAPSTONE spacecraft at its New Zealand launch pad ahead of a mission to the Moon.

    It's been quite a journey for CAPSTONE [Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment], which was originally supposed to launch from Rocket Lab's US launchpad at Wallops Island in Virginia.

    The pad, Launch Complex 2, has been completed for a while now. However, delays in certifying Rocket Lab's Autonomous Flight Termination System (AFTS) pushed the move to Launch Complex 1 in Mahia, New Zealand.

    Continue reading

Biting the hand that feeds IT © 1998–2022