The NetBSD project has “gone 2.0″ recently, with the launch of a blog and twitter, uhh…channel? I’m not sure what the proper term there is. This was bought to my attention by a blog entry by well-known NetBSD advocate Hubert Feyrer (Deutsch, English).
The most recent entry in the NetBSD blog is about the project’s participation in this year’s occurrence of Google’s Summer of Code. It links to a list of projects, two of which caught my eye.
First up is Lloyd Parkes’ “Miniaturise NetBSD” project, which aims to “produce a boot image for a system with no more than 4MB Flash / 16MB RAM, run a useful NetBSD router with DHCP client/server, IPv6 route solicitation/advertisement, PPPoE, and an 802.11a/b/g WPA access point”. I like this sort of project in part because I just find small, underpowered systems kind of fun, but also because it guards against bloat and bad design. If it’s a straightforward project to strip a system down to those sorts of specifications then it says something about the system’s simplicity. I feel like having this sort of anti-bloat guard for NetBSD is particularly important just now because there seems to be a gentle trend away from the project’s traditional lean and simple approach lately – putting an unusual web server like bozohttpd into the base system is one obvious symptom of this, and I fear that the recently announced Desktop project might accelerate this trend (although so far their discussions in the mailing lists seem to have been harmless and helpful).
Secondly and even more interestingly is Nhat Minh Le’s “XML command-line utilities for NetBSD”, which “aims at providing NetBSD with a lightweight, consistent, set of stream-oriented XML utilities, inspired by traditional Unix programs such as grep, join and sed, hopefully opening the way for similar support in other mainstream systems”. I am not a huge fan of XML and I much prefer to use formats like CSV, INI and YAML where they’re appropriate, but there’s no denying that XML is now the de-facto standard format for, well, anything. This standard becomes a whole lot more palatable with equivalents to grep and friends to make working with XML from the command line nice and easy. Furthermore, this project shows that this spirit of Unix is still alive in NetBSD (although, as the project description notes, this isn’t really a NetBSD project as such, because these tools will be useful on all platforms), and that makes me very happy.
Changing topic just quickly, in my last entry I mentioned in passing that:
I’m a big fan of reusing HTTP wherever possible because it makes life easier for developers.
I recently dug up the article Why HTTP by Timothy Fitz, which played a strong role in convincing me that this was a sensible stance to take. I don’t bring this up now arbitrarily, I want to write some more about it in a later entry, so this is just to get you and I both primed). Until then!
Quite a while ago now (toward the end of 2007), when I was freshly inspired to do more cryptography advocacy by the death of Itojun, “the IPV6 samurai”), I wrote a rant/essay called Anti-phishing Cryptography (it’s actually in a pretty bad state right now, it needs some structuring and completion) in which I lamented the fact that people in 2007 were being fooled by fraudulent emails into giving up the credentials for important services like Paypal or internet banking, despite the fact that digital signature technology which makes verifying the identify of an email sender largely foolproof has existed for literally decades. I tried to generate enthusiasm for a system where important services like Paypal or banks would digitally sign all official communications with their customers, and would make the keys easily available as metadata on their websites, with a well recognised and user friendly icon system, like that currently in place for RSS. Randomly returning to this idea a few years later, I’m struck by how much this overcomplicated the problem and how (seemingly) much better a new idea of mine is.
The idea is simple: when an email client like Thunderbird or Outlook receives an email from (purportedly) the address user@domain.com, it makes a HTTP request to a hostname derived from domain.com, perhaps something like keydiscovery.domain.com. The request can be on a port other than 80 (which means that keydiscovery.domain.com remains free for use as a website URL) and the URI can be some agreed upon standard with the username user included as a query parameter, e.g /getkey?id=user. A HTTP server on the other end responds with user@domain.com’s public key, in ASCII format, and then closes the connection. If the user doesn’t exist it returns a 404 like usual. Once the email client has the key (which it caches against the email address for future use), it can attempt to validate any signature present.
This can take place in a few seconds, completely invisibly to the email client user. Depending upon the possible results – key successfully found, signature is valid; key not found or signature not present; key successfully found, signature is invalid – the client can display a green, orange or red light respectively beside the email’s listing. Thus, without understanding anything that has actually gone on, even a clueless user who doesn’t know what a public key is can quickly grasp some significant security information about that particular email. If there’s a green light he knows the email is genuine. If there’s a red light he knows it is certainly a scam. If places like Paypal and major banks played their part by signing all of their emails (and their outgoing SMTP server could be configured to do this automatically to reduce the costs of retraining etc. and the risk of keys being stolen/leaked from low-level employees with insecure desk PCs) and making the public key available via HTTP at the appropriate URI and on the appropriate port, then people running phishing scams could not get away with spoofing a sender address which ends in @paypal.com, unless they were able to forge a digital signature, which at the moment is essentially impossible in practice. Any attempt to send such impersonating mail would raise an obvious red light at the user’s end.
Unfortunately, this idea does not kill phishing completely. Scammers could simply register domains which are superficially similar to those that they want to pretend to send email from, like paypaal.com (in fact, they often do this now in order to have somewhere convincing-looking to host web applications which steal credentials), set up a key discovery server for this domain and send signed emails that would get green lighted. It would be up to the user to realise that the email was from PayPaal and not PayPal, and that’s something that anybody could miss. So further measures would be required to help guard against this. I have ideas on how this might be done, but I don’t want to get this entry too off track by talking about them now. Besides, even if this system doesn’t solve the phishing problem completely, it is still cool and useful and a bold step in the direction of making public key cryptography easier for the public to use.
I’ve done a bit of googling and nobody appears to have written about this sort of idea before, although this may be because nobody has talked about it using the term “autodiscovery” (which I picked up from the RSS world, btw). The nearest I have found are some places (like here and here) talking about putting a tag in your blog’s HTML code to advertise your public key, so that people can do things like leave signed or encrypted comments on your blog without too much trouble. This is a similar-in-spirit but not-quite-the-same idea to the one I’ve proposed here. The fact that this is the closest idea I’ve found means either I’m the first person to have a great new idea (which I just can’t believe, given how simple it is), or (much more likely) there’s something fatally wrong with this idea and so everybody else who has had it has dropped it after some thought. Surely I must be missing something? Let’s think this through…
Suppose there’s a mail service out there somewhere that has not yet set up a key autodiscovery server. Could an attacker set up a fraudulent key server before them to impersonate their users? Well, no, since the hostname used to do the key lookup is derived from the domain part of the email address. An attacker can only set up a fake key server if they control the relevant domain name (excepting some sort of DNS attack, of course, which causes some users to mistakenly ask the attacker’s server for a key instead of the real one). This feature of the system limits impersonation attacks to people inside the same domain as the impersonated person. A disgruntled Microsoft sysadmin could establish a fake keydiscoery.microsoft.com and impersonate bill.gates@microsoft.com but he couldn’t impersonate scott.mcnealy@sun.com (and neither could Scott or one of his employees impersonate Bill). This is a weakness, but not a terrible one. Inside attackers are always going to be at an advantage over outsiders.
So fake servers don’t seem to be a problem. What about attacking genuine servers? Could an attacker exploit a buggy key server and overwrite somebody’s stored public key with his own? If the keys are served over a port other than 80, then even though they come via HTTP there is no need for them to be served by a “proper” webserver like Apache or Lighttpd (of course, in this case there’s no reason for them to use HTTP at all instead of some other invented-for-the-purpose protocol, but I’m a big fan of reusing HTTP wherever possible because it makes life easier for developers). They could be served by extremely small and lean specialist server programs which implement an extremely restricted subset of HTTP, close to HTTP/0.9 in simplicity. They would ignore any requests other than GET, and return a 404 for any URI other than the designated standard /getkey (or whatever the internet agreed upon). That’s it. They would have read-only access, enforced by the OS, to the keys themselves (some other program, less accessible to the public, could handle key management). The code for a server like this could be made so delightfully short and simple that you could realistically get all the dangerous bugs out of it.
I’m going to have to think about possible attacks against this system for a while. If there really are none then I think it’s a really exciting and important idea. I might go about trying to write a plugin for Thunderbird to implement a proof of concept. I have no idea how this will go, I don’t even know what language Thunderbird plugins have to be written in, or whether or not they would have access to a HTTP implementation. If anyone can see any weaknesses in this idea, please leave a comment. If the comment feature doesn’t work (which I’m starting to suspect is the case sometimes), then please email me.
My NetBSD-powered eeePC 701 webserver is still working just fine. The only downtime I’ve had since I set it up was when I once accidentally partially unplugged its power supply while trying to squeeze one extra plug into the same powerboard. I managed to get it out enough that the eeePC switched over to battery power but not so much that it was obvious at a glance, so I didn’t realise what I’d done until the battery discharged and I stopped being able to check my email. I intend to write a power management script to stop this from happening again. The output of apm on the eeePC is fairly informative:
Battery charge state: high
Battery remaining: 100 percent
A/C adapter state: connected
Power management enabled
Number of batteries: 1
A script that parsed this output ever minute or so and checked for changes in “A/C adapter state” could recognise when the power supply has come unplugged or when there has been a blackout and take appropriate action – probably emailing me a warning and also playing an audible notification through the in-built speakers. The same script could probably also force a graceful shutdown when “Battery remaining” gets to 10%. Once I’ve written this I’ll publish it here.
One thing that I’ve always been a little displeased about is that I haven’t been sure whether or not the screen’s LCD backlight was going out when I closed the lid. This typically requires the OS to be able to talk to the BIOS about the video card and non-mainstream OSes like NetBSD can’t always do this when the BIOS details have stupidly been kept secret by their manufacturer. On some laptops this is easy to check for – on my ThinkPad T42 the switch that gets depressed when you close the lid is clearly visible and you can poke it with your fingernail or a pen to test that the screen really does go out. However, this switch for the eeePC seems to be completely internal so the best you can do is get the lid 95% closed and try to peer in through the resulting gap to see what is happening. As you can imagine, it doesn’t work too well. Anyway, I really wanted the backlight to be off while the lid was closed if possible, since the backlight counts for a surprisingly substantial amount of the power consumed by a laptop, and one of the motivations for switching to the eeePC was to lower the power costs of all my hosting activities.
This recent blog post by Matthew Sporleder, who is also running NetBSD on a 701, explains how he managed to forcibly switch off the backlight but his solution involves having X.org installed (and running!). This seems sort of like overkill for me since I don’t ever plan to use X for anything else on the device. However, a comment on the entry by “jmcneil” suggested that vbetool might be of some help. So I installed that and sure enough running vbetool dpms off forces the backlight off even when the screen is open. Replacing “off” with “on” obviously gets it back on again. This seems like an ideal solution. The only problem I can see is that if I’m ever forced to work on the eeePC using its own screen and keyboard instead of remotely using ssh (for example when I’ve made a stupid change to my network configuration and I can’t get in via ssh) I don’t know how to get the screen back on (aside from very carefully logging in and running the vbetool command while blind!). None of the function buttons along the top of the keyboard for adjusting the screen brightness or toggling between the inbuilt screen and an internal monitor seem to wake it up. Still, this is likely to be such a rarely occurring problem that I think the power savings more than justify the inconvenience.
