Certificate Distribution Proves a Vexing Problem

Just determining how to securely disseminate keys for a new PKI system proves to be a challenge in itself.

I'm at the beginning of a project to rework my company's homegrown public-key infrastructure (PKI). Specifically, we want a system that will let us reissue keys as they expire without inflicting a lot of pain on users and administrators. We're looking at several different products. But even when we find the right certificate authority, we'll still need a way to get the right keys to the right users. This week, I'm working on coming up with a better certificate-delivery mechanism.

Just E-Mail It

Historically, we've e-mailed certificates to users in an encrypted attachment. But now, with everyone worried about e-mail-borne viruses and worms, we have to send these attachments through firewalls, and that's very difficult. We need to secure e-mail standards or use another method.

We decided to evaluate several different approaches and set up conference calls with vendors to discuss product details.

We had a useful discussion with one firm that offered a secure e-mail package. But we decided against this - or any vendor's - secure e-mail product. Why? Some of our customers use Secure Multipurpose Internet Mail Extensions, some use Pretty Good Privacy, and the rest use horrible, proprietary bolt-ons. We don't want to be the ones to synchronize it all.

As we evaluated possible distribution methods, it became clear that a Windows-based protected Web server was the right answer. With it, our users could authenticate to the Web site using a passphrase that we mail to them, and then our Secure Sockets Layer-enabled Web site would let them download their certificates safely and easily.

We bought a few applications that let us check who the users are and securely deliver the certificates to them. Unfortunately, these applications require a Windows 2000 system running Microsoft's Internet Information Server (IIS) and a SQL Server back end, and we don't normally support those in our externally facing infrastructure. We certainly don't have a Windows support team to ensure that these servers are kept up to date and monitored.

This opened up another problem: Given the sheer number of IIS Web servers out there, we knew our servers would be the target of many attacks. There are many known buffer overflow problems, and we expect a continuous stream of patches for new and old vulnerabilities.

To implement this system successfully and at a reasonable cost, we needed to find a way to protect ourselves from attacks during the time after a vulnerability is discovered and before our administrators are able to roll out patches - without leaving ourselves wide open in the meantime.

The best way for us to do this was to move from intrusion-detection software, which warns administrators of attacks against our devices, to intrusion-prevention software, which automatically blocks attempted attacks.

We ended up using Entercept Security Technologies Inc.'s Web Server Edition software. This tool from San Jose-based Entercept acts as a gatekeeper to the Windows 2000 application programming interface/kernel and filters and monitors requests. It automatically blocks attempts to carry incorrect instructions so that, for example, no buffer overflow attack can work. It adds to Web server processor overhead by a few percentage points, but compared with the potential cost of administrative time spent responding to incidents, the extra hardware costs to support this overhead were tiny.

Reasons to Worry

Of course, not even the most impressive protection layers can eliminate every security problem. We might be protected from buffer overflows and common worms, but you can always count on programming errors to leave security holes.

For example, an outside hosting and design agency manages our graduate recruitment site. We've encouraged the agency in the past to get their servers built to our standards, but part of the benefit of outsourcing is that we shouldn't have to worry about their security. Worry we did, though, when a graduate called to tell us he was playing with the forms on the site "and something funny happened." At this point, we normally roll our eyes and move on to the next issue, but he then explained that he'd been presented an error page that included the system administrator's user name and password.

A few calls to the design and hosting agency confirmed that he did indeed have the correct password. Apparently, the agency had accidentally let some pages that had debugging enabled go live. They quickly fixed the problem and changed their passwords. But it isn't good when the closest thing we have to intrusion detection is relying on Web site users to call us when we accidentally provide them with administrative credentials.

Of course, the Web site administrators shouldn't be using an administrator account to access the database, and they shouldn't have hard-coded user name and password details in the pages. We'll have to kick off a proper review of the whole setup because they obviously aren't doing a good enough job on their own.

I'd like to think that our in-house servers will be more secure than theirs when we install IIS, but I have a feeling that we may face a similar learning curve.

Copyright © 2002 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon