No Such Weblog

I had earlier blogged the Bonn Books Outdoor project. The public bookshelf is alive and well, after some mechanical problems with the doors were fixed.

In Buxtehude, there's a similar, but slightly different project (photo here): Instead of setting up a dedicated bookshelf, they are reusing abandoned phone booths, with bookshelves installed inside.

The absurdities and chilling effects of today's intellectual property environment: Let's assume you buy a CD (say, "feels like home" by Norah Jones) online, but it turns out to be a non-CD that you can't listen to (you missed the fine print). Let's assume you rip it on some old PC, and then copy the MP3s to your laptop -- so you can actually listen to the music you paid for. Because the technology put in place by the control freaks at IFPI is much more effective at keeping people from playing the music (in particular on modern devices) than it is at keeping them from copying it.

Just assume all this. Could you do and blog it, without risking legal trouble? Could you discuss the software you used for ripping the CD?

To stay out of this kind of questions, stay away from copy-controlled CDs. Also, spend at least as much money on funding the excellent people at EFF as you spend on funding an incredibly arrogant cartel that happily takes your money, but delivers crap.

Writes Kurt Pritz: The ICANN Proposed Budget for fiscal year 2004-05 is being posted today at 4 PM Pacific time.

Verisign's case against ICANN basically was thrown out of federal court on Tuesday, with two weeks for Verisign to amend its claims. Part of the suit may end up in California state courts.

Bret Fausett lives in the right time zone, and has all the news on this.

Tim Berners-Lee's New top level domains considered harmful (Karl Auerbach's response here) makes a number of points of varying quality.

Kevin C. Golden to John Jeffrey: Finally, please let this letter serve to advise you both of VeriSign's intention to participate fully in the process for the selection of the operator for the .net registry, and that VeriSign intends to compete for the award of the .net Registry Agreement.

So I couldn't resist, and upgraded my laptop to Fedora Core 2 -- welcome to the better world of Linux 2.6, or so. (This is all on a Thinkpad R40, no dual-boot.)

First of all, ACPI seems to work -- until you attempt to suspend the laptop, which just doesn't work (or, when done through the /proc interface, requires removal of the battery to restart the computer).

So add "acpi=off" to the kernel's command line, and reboot. APM works better than with FC1 in some areas -- X11 doesn't seem to crash the entire machine any more after suspend/resume! -- and worse in others -- IRDA doesn't work after suspend/resume; I'm now trying to fix this by moving the serial driver to a separate module. As usual, USB drivers need to be removed from the kernel before putting the laptop to sleep.

Overall, Fedora Core 2 by no means feels like a revolutionary improvement -- some of the changes I had to make to FC1 to make it work smoothly are in this version; some other changes are needed.

Later: The machine has crashed once, with symptoms that were quite similar to the X11 afterresume crash. So back to 16bpp for now. IrDA works nicely once the serial driver is moved out of the way.

Memo to self: jpilot is not particularly smart about recognizing character sets when running on modern Linux systems, such as Fedora. This note points to the configuration option that's needed.

The GNSO Council's .net committee is currently discussing criteria to be used in picking the next registry operator for .net. There's some discussion about the role that registry-level pricing should play as a crtierion in evaluating the bids: Should the lowest bidder be selected, once baseline technical criteria are met? Or should overall "value" of the proposals (whatever this be) be considered, with price only being a minor factor in this consideration?

I'm arguing that either, baseline criteria + price should be used in evaluating bids, or that "value" needs to be defined, quantifiably: If the GNSO decides to say that apples can balance oranges, then it also needs to find a way to compare them.

WLAN is insecure, and should be secured by adding a VPN as an additional layer of security, says conventional wisdom. An approach that's still being deployed uses pre-shared keys for ISAKMP phase 1, and XAUTH in phase 2.

As has been pointed out by others before, these setups are inherently insecure: Any party with access to the IPSec shared "secret" (often found on public web servers) can impersonate the VPN gateway; clients will happily supply the fake gateway with login credentials. Frequently, these are persistent passwords that can also be used to access anything else in the networks affected.

Theoretically, the easiest exploit of this kind of problem consists in setting up an access point and a machine that runs a DHCP server and an off-the-shelf ISAKMP/IKE daemon which doesn't really do XAUTH, but just records passwords. This isn't a real MITM attack -- but then again, the credentials one can reap are considerably more valuable than the additional data that one could get by doing a true MITM, so even this straight-forward reference attack can do considerable damage. (Think about some thousand Kerberos passwords.)

Unfortunately, it turns out that this theoretical attack fails due to (1) idiosyncrasies of the CISCO VPN client (bad packet lengths), and (2) due to the fact that none of the easily available open source IPSEC implementations appear to implement both XAUTH and ISAKMP's aggressive exchange (which seems to be typically used by the CISCO client, and is always used by vpnc) -- openswan-1 may be an exception to this, but I wasn't able to get it to run here. I can only speculate that the lack of availability of a ready-to-use attack tool contributes to the continued deployment of this kind of systems.

Still, it is relatively easy to implement the simple attack: vpnc comes with all the library routines one needs to comfortably manipulate ISAKMP packets. Starting from vpnc, implementing a simple ISAKMP responder that takes the client through phase 1 and obtains credentials in phase 2 is a matter of a couple of hours on a lazy holiday.

The message here is that the attacks against pre-shared key networks with XAUTH are anything but academic or difficult: Implementation is easy. I would be extremely surprised if no implementations were floating around in black-hat circles. It will only be a matter of time before one of these programs becomes readily available.