Joe Auricchio

Thanks, Blink, for that useful and informative tip. Now I know that’s how the Internet works.

For the past ten months or so, I’ve used only Jabber and Google Talk as IM services. No AIM, no MSN, no Yahoo. I signed off of the others, permanently as it seemed at the time, because I believed I need to do everything I can to help encourage an open XMPP network, analogous to the open SMTP network that delivers email.

Recently I’ve realized that trying to get the whole world to move to Jabber is hopeless. There’s simply too much inertia in the big three legacy IM systems. Little nudges will not be enough, because to the vast majority of people, the reasons to switch seem like unimportant technical details. The only thing that will pull people permanently away from the big three is when the big three themselves either move to jabber (unlikely) or die (also unlikely).

Meanwhile, the open network is very slowly appearing. Companies and organizations are slowly rolling it out. I haven’t heard of any universities providing Jabber accounts to their students, yet. Ahem. (Hi DJ!)

So I’ve decided that my idealistic goal of moving the world to an open XMPP network is not worth cutting myself off from my friends. It pains me to write it, but I’m going back to AIM.

I’ve re-added most people whose screen names I remember. If you want to talk on AIM again, and you don’t see me, leave a comment or email me, and I’ll re-add you.

I’m also shutting down my Jabber server (tongos.com), and I’m combining both Jabber accounts (tongos.com and gmail.com) into one new gmail account (j.auricchio). I still prefer using Jabber over AIM, when I can.

http://forums.worldofwarcraft.com/thread.html;jsessionid=32DA4C09BEB07855088A6F20EBB8C4DE?topicId=11211166&sid=1

Plus, amusing tie in with World of Warcraft. Hi, Cano.

It is impossible to enjoy idling thoroughly
unless one has plenty of work to do.

Jerome K. Jerome (1859 - 1927)
via http://www.songbirdnest.com/node/639

We’ve had some downtime recently. Two and a half weeks’ worth. Today I’m going to write about that.

On the evening of August 7th, I drove back up to Cambria. In a later post I’ll talk about what happened after that.

A few hours after I left, my server went down. Rushi tried to restart it, but lilo threw an error on startup. He and I tried to debug it, and we decided to boot a liveCD and re-run lilo. Rushi booted Knoppix, re-ran lilo, and restarted. The machine crashed on boot. Repeated restarts would cause it to crash in different places on boot. Clearly, something was up. DJC tried his hand, but the machine just kept crashing. Eventually liveCDs would crash, and I even got the BIOS to lock up on the boot-menu - several times. Conclusion: bad mobo.

So yesterday Mark, Rushi, Scott, and I all went to Fry’s. We talked for a while in the motherboard section, and I finally settled on an Abit KV-85 and a Sempron 2800+ (socket 754, the good one). Cost: $90.

I had a nightmare of a time trying to get it all up and running again, greatly assisted by Rushi with moral support from Mark, Scott, and Ben. I was hampered especially by, well, lilo, which was in fact legitimately broken unrelated to the mobo troubles. So I’ve negotiated with it and /boot is no longer a software raid1. That means if hda dies I’m in some hefty trouble. (Hear me baby? Hold together.)

Or, Vegas Baby Vegas!

So I went to DefCon this weekend.

After Scott and DJ returned from the 2600 meeting on Friday night, they asked if I wanted to go. Since DJ, a few others, and I had a final exam on Saturday night (7-10pm), we’d all figured we couldn’t go. At 2600, though, somebody suggested that we take off immediately after the final; we’d be there by 1 or so, and he knew somebody who had a room where we could stay. So DJ and Scott made preparations to go, and asked if I was interested. I thought for a while, about how awesome it would be, and how crazy it would be, and how scary it might be, and how boring it might be, and eventually I decided I might as well because I may never even have the opportunity to do something so crazy again.

So I left my PowerBook at home, and took everything out of my wallet except proof of car insurance, AAA card, medical insurance card, and cash; and put my drivers license in my shoe. DefCon is possibly the worst place on earth to lose a DL - it WILL make its way to identity thieves, and I guess these days a DL# is enough. DJ made more extensive preparations, since he brought his laptop.

After the final, we took off up I-15. Shortly after we got on, around Carroll Canyon Rd, I think I saw a DeLorean. It exited before we could get closer, though. We stopped for burgers and gas at Corona. Somewhere just this side of the CA/NV border is a road called Zzyzx Rd, which has an interesting story behind it.

By 1:15am we were rolling down the Strip. It is, in fact, crazy. We found the Riviera, parked, and headed up to the Skyboxes overlooking the convention halls - where all the parties were. As we waited for David, our contact, we sat in the hallway and Scott and DJ tried to get online. Scott’s machine got unstable after just a few minutes — might have something to do with using an Intel wireless card. I enjoyed watching the people walking by in various states of inebriation discussing obscure issues of computer security. A pair of guys walked by, party-hopping, one saying to the other “…and we’re not gonna drop anything out of this fuckin’ skybox, are we??” We met up with David and hung out in his skybox for a while. Eventually we headed off toward the Hilton, where David had a suite, and crashed.

The next morning we woke up around 11 and lazily got ready. We helped David get packed, and gawked at his 4U two-motherboard machine with around 10 FPGA cards. He’d used it for his talk on cracking wireless encryption in real-time. We went to eat at the Riviera’s champagne brunch. No cards, we just came back to the table and there were four cups of champagne. Only in Vegas would champagne be served from a pitcher into small plastic cups.

We cruised around the vendor area and bought some stuff. I got three very nice t-shirts and an EFF membership. DJ renewed his EFF and picked up some stuff, I didn’t see what. Scott got a few shirts (one free) and a diskless thin client: 800MHz cyrix, some ram, full complement of ports, one PCI slot, and CompactFlash slot, for $60. I think he’s gonna make it his router, once he refactors Athena.

After that, we caught the closing ceremonies. Interesting stuff; next time I would like to see some of the CTF games.

We met some cool folks around our age, one from MIT and one from Santa Cruz, had dinner with them at a very nice Korean restaurant down the street, said our goodbyes, and headed home.

I’ll upload pictures later. Remind me.

Scott has a much shorter take on the whole thing.

(allusion)

On Monday, I bought a Seagate 300gb HD at Fry’s for a record low price. On Tuesday evening, after a bit of trouble with the power supply, I got it installed and started a bad block scan.

It’s still running, on Friday night as I write this. It’ll probably finish sometime during the night. So that’s around 80 hours to read then write every sector on the disk 4 times. Twenty hours to fill the disk.

That’s insane.

Who could possibly need that much space? I sure don’t. Even after I integrate it into the RAID ((We’re going from a 160gb 2-drive RAID 1 to a 320gb 3-drive RAID 5 on the same spindles without rebooting. Because I’m crazy like that.)), I’ll still have a few hundred gigs free on the system. I might have to start stockpiling films, more than the few Kurosawas I’ve torrented. Or perhaps I’ll make every vhost on the system a usermode-linux virtual machine, each with a ~4gb filesystem image.

Remember when hard drives and filsystems couldn’t handle 4gb? The progression of technology is amazing to me, and I’ve only been at it ten years or so. What must it be like for real old farts like these fine people? Apparently, Creed doesn’t have a site these days?

6.20 Why should I care about compatibility with the past?

This is one of those questions in which the answer never convinces those who ask it. Somehow, everybody who ever asks this question ends up answering it for themselves as they get older, with the very answer that they rejected years earlier.

UW IMAP Toolkit Frequently Asked Questions

Via Bruce Schneier’s blog. Read it first.

When you reduce “admissibility” to a more simple and general form, it becomes the question “What happens to the data after it changes hands from the provider to the user?”. At some point, the handoff must occur, and beyond that point the server can have no knowledge or influence on the data’s further disposition. A few technologies, such as end-to-end encryption (SSL, etc) can help move the handoff to the client endpoint’s network stack, but at some point the data is decrypted, and it becomes accessible to the user’s code and eyeballs. This is the intention of a good secure system — to give the right data to the right users.

With that, necessarily, is the risk that other code and eyeballs will steal that data from the intended recipient - and that is a completely separate security problem that can only be solved on the client side. The parameters of the problem are the same “Four As” (or “CIA”) we already know. The security of the entire system scales like a fractal, to smaller and smaller scopes, until at last we have CRT to eyeball and fingers to keyboard (which leaves the realm of computer security and becomes an old-fashioned physical security problem) ((I’m not trying to minimize the value of physical security; if anything, it’s a lot harder than computer security. It’s merely a different kind of problem, and a different set of people need to work on it once it reaches that level.))

The security of the client is a problem; but it is neither the server’s problem nor a problem the server can solve at all. A server can never have any assurance whatsoever that its client is not vulnerable to attack. There are two ways for the server to obtain an answer to that question: the server can invasively investigate the client, or the client can claim to the server that it is secure. If the server invasively investigates the client, it can be tricked into investigating a clean-looking virtual machine. If the client claims it is secure, or rather, that some sort of configuration-management software running on the client claims the client is secure, that response can be spoofed by an attacker, or the configuration-management software can be compromised.

If this whole server-trusting-the-client’s-configuration sounds vaguely familiar, it’s exactly the same problem that ruins identd: the trust isn’t placed in identd, the trust is placed on the sysadmin of the remote machine. But how do you know to trust them? How do you know their machine is not lying and has not been hijacked? You cannot, and that is why identd is not a usable authentication system. ((So why do most IRC networks still require it, or make you wait thirty seconds until the request times out?))

Ultimately, the admissibility question reduces to “What are you going to do with this data after I give it to you?” This is not a new question, nor is it an easy one to ask and answer. Some of its unhappier answers include users taking laptops home after work where they can be burgled, or users deliberately giving or selling data to third parties. These are all completely outside the design of the security system. ((This problem of “what are you going to do with the data, now that you have it?” applies at all levels, including within the server as requests are processed, an area I think may be overlooked too often. This is the level at which you ask questions like “Do I trust that this data will not be snooped out of the kernel’s networking stack, before it’s sent out the ethernet port?”—don’t laugh, it’s happened!))

Until the day when data itself grows teeth and can defend itself against misuse, we have to carefully limit who we authorize, do our best to teach how to secure their own environments, and finally, trust those authorized users and their environments. That’s the way we do things now, and it’s not always a very fun way (especially that second part), but it’s the only way.

I hope somebody’s working on that teeth thing, though.

A final word: One-time passwords and time-based credentials (Opie, SecurID…), properly implemented, can make all forms of sniffing a LOT less profitable. The first credit card company that uses rotating card numbers based on a SecurID-style token is going to get my business. Alternatively, I’ve heard some European banks give customers scratch-and-sniff cards with a few dozen one-transaction authorization codes. That’s a nice low-tech solution that’s just as good at the end of the day.