Julian C. Dunn

Preamble: Today was my last day at FSC Internet but I started writing the piece below some time ago. It still needs some work, so it’ll probably get a few more edits as time goes along, but I wanted to post it up here to mark the day I left the field of Internet security.

Ever since I started working for an Internet security company, I’ve been using PGP (GnuPG) a lot more both in my daily work, and at home. Even though PGP has been around for ages, it hasn’t been widely adopted. Even other secure e-mail technologies like S/MIME have not enjoyed wide acceptance either. I started to ask myself why, and I’ve come up with a number of explanations as to why secure e-mail hasn’t taken off:

• Insufficient size of critical user base. This is the classic technology adoption problem that faced inventions from the cell phone (who are you going to call if nobody else has one) to the VCR (what are you going to play in your VHS VCR if all the movies are still in BetaMax). With PGP, the problem is compounded by the fact that the trust value of your key is affected by the trust value of the keys of the peers that have signed your key; if nobody signs your key, the trust value of it is very low.
• No interoperability between competing secure e-mail technologies. In part, we can blame the invention of proprietary
  and closed technologies like that "Secure E-mail Certificate" widget in Microsoft Outlook. PGP has been around for years; why didn’t they just use that? On the other hand, PGP itself has been through many mutually incompatible revisions; PGP 2.x; Network Associates PGP 5.0, PGP 6.0, and finally, GnuPG as an open-source alternative to PGP proper. Such needless forking does nothing to build the image of secure e-mail technology as reliable and robust.
• Poor GUI frontends to PGP. Before writing this piece I decided to do some investigation as to what frontends were out there, that are still being actively maintained. There certainly aren’t a lot. On this Debian GNU/Linux box I picked out two that appeared worthwhile: gpgp and kgpg. gpgp as I soon discovered was out of date. kgpg core dumped when I tried to retrieve keys from a remote keyserver. Neither of them implements the features that I would want in a front end, namely, easy modification of all parameters of a given key on the keyring, including trust levels, adding and removing signatures, and so on.

Fundamentally, though, these aren’t insurmountable problems. Technical and adoption issues, while irritating, are comparably easy to fix. (Okay, convincing Microsoft to use PGP in Outlook might be more difficult, but even the PGP GUI is a problem waiting to be solved.) It’s my belief that the lack of interest in secure e-mail technologies as a whole is motivated by people’s desire to not only be anonymous on the Internet, but to never be held accountable for anything they say.

Perhaps I’ve been hanging around too many marketing weasels, but there are plenty of folks who don’t want to be held accountable at a later date for some bald statement they made today. I’m sure that the Enron and WorldCom executives wished they hadn’t sent certain e-mails that are now sitting in evidence vaults. Those e-mails would probably carry even more weight (against said executives) if they were digitally signed with the originator’s PGP key.

The lesson to be learned here is one that relates to human nature. Once you have attached a digital signature to something, you can’t take it back. Ever. Particularly if the message is in the public domain, it can come back to haunt you. This is not generally what people want to hear; it makes them feel less secure, not more. This is the critical flaw in secure e-mail technology.

After four months I am leaving FSC Internet to get back into the field of software development. While security is interesting, it, like many things, is only interesting to me if I don’t have to do it full-time.

This doesn’t mean that I’ll stop weighing in on security matters. Heck no. I have a few parting thoughts as I wrap up at FSC.

Today’s Daily Dave is, as usual, pretty entertaining. It’s not quite as cohesive as past entries, since he tries to talk about a whole plethora of topics, eventually winding up at a discussion about how many security companies are being co-opted by developing “partnerships” with the very industries they are supposed to be protecting. In principle, I agree with him: from a 30,000 foot view, it would seem that any security company that’s been hired to assess vulnerabilities in a client’s products would not do anything to embarrass the client.

However, any ethical security company would still disclose security vulnerabilities to the client, and to work with them to deliver a measured advisory and response to the community. Failure to do this means the security company isn’t worth its salt.

In the specific case Dave mentions in his article, there is a glaring remote root exploit in the code for RealNetworks’ streaming media server products. He is claiming that the various security companies that RealNetworks has hired over the years to do vulnerability assessment are accomplices in this massive coverup to hide the security hole.

I don’t particularly buy this point of view. By the principle of Occam’s Razor I believe there is a simpler explanation: the security companies that RealNetworks hired are simply incompetent. In the article Dave says that the hole can be found within 10 seconds of starting up SPIKE (which I’ve mentioned here before in this journal) but there’s nothing to prove that the security firms actually tried to use this tool, or any other tool. For all we know, their "code audits" could have been a complete joke — and not necessarily just because they were working for RealNetworks. Perhaps it was just a quick smash-and-grab for them to assuage the vulture capitalists.

I have one more viewpoint to post on security issues — it’s about PGP/GnuPG and why I think digital signatures/encryption of correspondence isn’t more widely used. I’ll tidy it up and post it on Wednesday, my last day at FSC. After that, I’m on vacation to NYC for a few days before starting my new position as a software developer for the CBC.

Now that the California gubernatorial race has turned into a complete circus sideshow, with both Arnold Schwarznegger and Larry Flynt of Hustler running, I’m suggesting that Darl McBride should mount a campaign, as well. Since the state of California isn’t doing so well financially, he can mount frivolous lawsuits against other states in an attempt to prop up the economy.

In fact, he could have the State of CalifOrnia (SCO) claim to own the copyright to the concept of rolling blackouts, which they purchased from PG&E. Then, he can sue, say, Idaho, for initiating blackouts without paying proper licensing fees.

Or perhaps, after IBM’s lawyers are finished breaking his spine on the Catherine wheel, he’ll just have to find another ailing public company in need of a business model that involves suing people.

Pardon the slight profanity; I don’t generally like to swear when I’m trying to make a point, but I didn’t invent the name of this site.

The views espoused by the author are obviously not much different from those in this excellent article in USENIX’s own journal, ;login:. (You’ll need to be a member to access that link, by the way) I’ve complained before about the proliferation of poorly-configured, poorly-managed Linux boxes taking over from the Windows boxes. It’s obviously still continuing to happen. Of course, the vendors are partly to blame, too. When the author of linuxforbitches.org writes about /var being an inappropriate place for web content (I wholeheartedly agree) you have many vendors to thank for that.

I lay the blame for the kernelized web-server, though, at the foot of Linus himself. Given that Linus is so militant about accepting patches, idiotic or not, I’m surprised — no, shocked — that he accepted this one. Considering that many kernel hackers are the same folks who probably bitched and whined about insecurity and instability when Windows NT 4.0 moved the drivers from user mode to supervisor mode (or Ring 1 to Ring 0, I don’t remember the exact terminology), the kernelized web server is a completely brain-damaged idea. It should be removed from the kernel at once, if it hasn’t already been so excised.

You know, despite all the claims about Linux’s stability, it still has a long way to go before it achieves the stability level of the BSDs. Under heavy workload, Linux still doesn’t cut mustard. Andrew Hume from AT&T Research presented a paper at HotOS-iX entitled Operating Systems: Shouldn’t They Be Better? True, he takes Solaris 2.6 to task in this paper as well, but the Linux flaws he describes are pretty shocking (these are from David Oppenheimer’s summary notes in August’s ;login::

Hume described eight problems the Gecko [his billing system] implementers experienced with Linux (versions 4.18 through 4.20), including Linux’s forcing all I/O through a file-system buffer cache with highly unpredictable performance scaling (30MB/sec. to write to one file system at a time, 2MB/sec. to write to two at a time), general I/O flakiness (1-5% of the time corrupting data read into gzip), TCP/IP networking that was slow and that behaved poorly under overload, lack of a good file system, nodes that didn’t survive two reboots, and slow operation of some I/O utilities such as df. In general, Hume said that he has concluded that "Linux is good if you want to run Apache or compile the kernel. Every other application is suspect."

The problem with many people measuring "stability" of Linux is that they think it’s a relative measurement: as long as it’s more stable than Windows, then it’s good. This is obviously a stupid way to look at it. Just because my Kia[1] doesn’t have exploding tires, doesn’t mean that it’s a particularly safe car.

People working on performance and stability in the Linux kernel are far outnumbered by the people trying to get their little pet project into the tree — vis à vis the kernelized webserver. Admittedly, performance and stability aren’t the most exciting research areas, but making Linux as stable as the BSDs is critical to its long term success. I mean, who cares if Linux can run on a zSeries or S/390 if the thing goes down like a ton of bricks when you throw a heavy workload at it?

Ultimately as a system administrator, I care much more about stability, and failing that, predictable, recoverable failure, rather than "feature-niftiness". When you have 1000 user accounts to manage and you get DDoSed, I want an OS that is feature-conservative but rock solid.

And that, in a convoluted way of my saying so, is why I don’t run Linux on my servers.

[1] I don’t, for the record, own a Kia.

I’m just waiting for SCO to declare itself in violation of its own trademarks, and sue itself.

Ed Foster pointed out in a recent GripeLog entry that TicketBastard‘s privacy policy is a complete joke. To paraphrase the point of the article: If you have ever bought a ticket from TicketBastard, they have reserved the right to sell all your personal information to their "Partners" and they specifically state in their privacy policy that you may not ever opt-out of receiving spam from their "Partners".

Although we would all love to avoid TicketMaster, unfortunately they have a monopoly in this country — behold, my friends, the American Dream! Anyway, if you can’t find a patch, at least find a workaround: my workaround would be: a) Don’t buy tickets online through Ticketmaster.CA or Ticketmaster.COM; b) Pay cash when you buy Ticketmaster tickets in person at the Ticketmaster outlet; c) Give fake credentials if the ticket clerk asks you for them (although I can’t see why they would).

I’m aware that this behaviour would probably tip off the authorities in the police state we call the U.S.A., since it probably matches some kind of Terrorist Profile generated by the Abteilung der Faterland-Sicherheit. If that isn’t ironic…

If you get the Daily Dave newsletter run by Dave Aitel over at Immunity, Inc. you’ll already have seen this. In a recent message he pointed listmembers to an internal FoundStone memo forwarded to that fantastic site, InternalMemos.Com.

I really will just let that memo stand on its own. There’s hardly anything to add but to state the obvious: marketing people are weasels. (See my previous entry on July 5th for Scott Adams’ bang-on perspective on marketing drones.)