LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityDNSCurve: an alternative to DNSSECThe Domain Name System (DNS) has been with us for a long time, turning host and domain names into IP addresses. Along the way, numerous flaws have been found in the protocol, including last year's Kaminsky DNS flaw, which just added to the clamor to see DNS replaced. But, DNS still hasn't gone away, and doesn't look like it will anytime soon, at least partially because its replacement, DNSSEC, doesn't really resolve all of the problems, and it creates some of its own. A proposal by Daniel J. Bernstein (aka djb), called DNSCurve, has some interesting features that might make it a viable alternative to DNS and DNSSEC—perhaps one that can be widely adopted. Bernstein, author of qmail and djbdns, has a reputation for creating secure software, but he tends to play by his own rules. Both qmail and djbdns use Bernstein's own monitoring and inetd replacement, rather than using the "standard" UNIX tools. But, his results are good, the security guarantee he offers for qmail (and a similar one for djbdns) have yet to be claimed—though some argue that is because Bernstein himself makes the final decisions as to what qualifies. One thing is clear, though, his djbdns did anticipate the Kaminsky flaw, and didn't need to be patched when most of the other DNS servers did. In some ways, DNSCurve continues the Bernstein "maverick" trend. The fundamental difference between DNSCurve and DNSSEC is that the latter set out to ensure that there would be no cryptography necessary on each query. It does that by pre-computing signatures, which makes it vulnerable to replay attacks. Instead, DNSCurve embraces per-query encryption, but it does so by leveraging an encryption algorithm, called Elliptic Curve Cryptography (ECC), which is much faster than RSA. Part of what makes ECC more efficient is that it can use much smaller keys than RSA (256 bits vs. 1024 or more bits) to give the equivalent level of security. In addition, the best known attacks on ECC haven't gotten any better in the nearly 25 years since it was introduced. In a recent presentation [PDF], Bernstein shows a benchmark of server side performance: "Using this software, a low-cost PC with a 2.4GHz Core 2 Quad CPU can encrypt and authenticate 50 billion packets/day to 500 million clients. [...] The total load on .com is 38 billion packets/day from 5 million clients.". Bernstein uses a particular curve, Curve25519, for DNSCurve. It is based on a "convenient" prime, 2^255 - 19, which is where it gets its name. That curve is the subject of a paper [PDF] by Bernstein entitled "Curve25519: new Diffie-Hellman speed records". ECC is thought to be a patent minefield, but Bernstein disputes the idea that Curve25519 is covered by patents. As with so many of the newest technologies, though, patent problems are something to keep on eye on regarding DNSCurve. DNSCurve also changes the way nameservers for domains are named. Instead of arbitrary hostnames, like ns3.lwn.net (an non-existent example), the ns3 portion would be changed to an encoding of the domain's public key. In that way, no additional packets need to be sent to handle the key exchange, as the normal DNS query sequence would provide that name. A DNS query would consist of a message that contained the client's public key, along with the actual query, encrypted using the server's public key. The response would also be encrypted, this time using the client's public key. In both cases, the packets would be signed in such a way that each side could verify that the packet came from the right host. The DNSCurve web site has a wealth of information about DNSCurve, and how it differs from DNSSEC. For the most part, it protects against various DNS-based attacks better than DNSSEC, but there are a few areas where DNSSEC is more secure. In particular, private keys on DNSSEC hosts cannot be compromised by an attacker gaining control of the DNS server—provided the administrator has removed the key from that server. Because DNSSEC pre-computes the encrypted data, the private key is not required to be installed on the server, in contrast to DNSCurve. DNSCurve is just a part of Bernstein's effort to see the internet encrypt all of its traffic. His vision is that by using ECC and Curve25519 (or some other, efficient, but strong, encryption), there would be no plaintext traffic on the net. That vision is a sensible one, whether Bernstein's particular implementation ideas are adopted or not. Eventually, universal encryption of internet traffic is something we are very likely to see.
Brief items OpenSSH updateOpenSSH maintainer Damien Miller has responded to the rumors of an active OpenSSH exploit in the wild. "I don't have any non-public information. I have exchanged some emails with one of the victims of the alleged sshd 0day, but he was not able to provide any evidence that the attack was sshd-related. In particular, I spent some time analysing a packet trace that he provided, but it seems to consist of simple brute-force attacks. So, I'm not pursuaded that an 0day exists at all. The only evidence so far are some anonymous rumours and unverifiable intrusion transcripts." This doesn't mean that nothing is going on, of course, but there is reason to hope that this is a false alarm.
Attempted Break-In on www.centos.orgCentOS is reporting that there was a break-in attempt made on the www.centos.org server. Due to an "administrative error", the Xoops content management system was abused to put some content onto the web server. "As far as we can see there has been no data or binary injected into the system or taken from the system. The machine hasn't been used as a source for sending spam (in the widest possible meaning) either. [...] We have been able to identify the source of the attacks, but have not been able to find out if the files have been put there through a compromised user account in the Xoops system." Click below for the full text of the announcement.
New vulnerabilities drupal: multiple vulnerabilities
ipplan: cross-site scripting
kernel: denial of service
libtiff: denial of service
mod_security: denial of service
nagios: arbitrary program execution
ocsinventory-agent: insecure module search path
openswan: input validation flaws
phpMyAdmin: cross-site scripting
pidgin: denial of service
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||