Server and client certificates aren't yet widely used for authentication, but that's changing fast. Here's a progress report.
Jon Udell
At an Internet conference in 1995, Netscape cofounder Jim Clark said he had concluded that government control of cryptographic keys was inevitable, so we might as well get used to the idea. "Why are you advocating a hierarchical, patriarchal model?," an irate listener jumped up and shouted, adding that it would violate everything the Internet has taught us about building cooperative systems. "Because it's what I think," said Clark.
Today, however, Netscape finds itself at the forefront of a movement to create a secure Internet that looks much less like the world of Big Brother and much
more like the loose federation of systems that the Internet has always been.
As electronic credentials begin to replace plastic ones, it's likely (and desirable) that you'll continue to use many pieces of identification issued by many autonomous authorities. Besides credentials from banks, schools, and libraries, you'll hold credentials from other kinds of certifying authorities, including, perhaps, BYTE.
I'm confident that digital IDs will be the right way to regulate access to subscriber-only areas of the BYTE Site. To that end, I'm experimenting with three uses of digital IDs -- to secure a Web server, to authenticate Web clients, and to sign and encrypt e-mail.
When these elements come together smoothly, they'll deliver significant long-term gains, but until then, they'll cause a lot of short-term pain. Discomfort is inevitable because the technologies for electronic privacy are logistically daunting. Before we can routinely apply them, we must learn more than many of us wanted to know about the hitherto esoteric realm of public-key cryptography.
To estab
lish Secure Sockets Layer (SSL) sessions with browsers, a Web server needs to hold a kind of digital ID called a server certificate. Why? Two reasons.
First, the certificate has the public key that the browser fetches so it can encrypt messages it sends back to the server. (One of those messages, sent as part of the initial SSL handshake, is the session key that the server can use to encrypt its traffic with the browser.) Second, the certificate carries a signature that binds the server's public key to an identity. In BYTE's case, for example, VeriSign's signature on our digital ID means VeriSign (
http://www.verisign.com/
) promises that the server presenting that ID really represents BYTE. For a year's worth of this assurance of authenticity, backed by a paper trail, we paid VeriSign $290.
Last summer, whe
n I bought that certificate, VeriSign's fulfillment operation was in a state of disarray quite at odds with its commanding ownership of the fledgling certificate-authority (CA) industry. What should have taken only two weeks stretched to over two months, as VeriSign scrambled behind the scenes with a short staff and antiquated equipment.
That's all fixed now, and it's a good thing for VeriSign because the list of CAs that's preloaded in Navigator and Internet Explorer has gotten much longer recently. No matter which CA you choose, the procedure to acquire a certificate will work roughly this way:
1. Generate a key pair.
Web servers that support SSL come with a tool for this purpose. For our Microsoft Internet Information Server (IIS) 1.0, it was:
c:> keygen password keyfile requestfile CN=www.byte.com, O=BYTE, L="Peterborough"
This created a file containing a private key, and a request to sign the corresponding public key and thereby bind it to the identity expr
essed in X.500-speak.
2. Do the paperwork.
For our certificate, that meant a letter from a Webmaster (me) signed by a boss (editor in chief Mark Schlack).
3. Send the request file by e-mail or Web form,
snail-mail the paperwork, send a credit-card number through one of these channels, and wait.
4. Receive the signed certificate and install it.
Now you can turn on SSL, point a browser at an https:// uniform resource locator (URL) on your server, and establish a secure connection.
Hassle-Free Certificates
For real electronic commerce, there's no way to shortcut this procedure, nor would you want to. The value of the certificate you're buying depends on nothing but the reputed diligence of its signer. However, for development and testing, you can grab any old certificate and be off and running with SSL.
The first quick fix I found was Sioux. It's an Apache-derived Web server that uses Eric Young's SSLeay (pronounced "slee
"), a freely available implementation of SSL. Sioux comes with a demonstration key and certificate, and it starts right up in secure mode.
Another source of instant gratification is
http://www.xcert.com/
. At Xcert Software's site, you can try out the things that CAs do. You can generate your own CA certificate, use it to stamp out your own "brand" of server and client credentials, and even manage the database of certificates that you issue. I used server certificates I created here to activate SSL on several test servers and my client certificates to test how these servers can in turn authenticate clients. A kit of CA tools will be included with the certificate servers forthcoming from Netscape, Microsoft, and others. Thanks to Xcert's early public demonstration, however, developers haven't had to wait.
Reciprocal Authentication
Since the advent of Netscape Navigator 1.0 and Commerce Server 1.0, the Web has supported one-way authentication. If you connect securely to the BYTE Site, you implicitly accept that it represents who VeriSign says it does. (In fact, you can't connect securely to the BYTE Site yet, for bureaucratic rather than technical reasons.) However, there is no reciprocity in the basic SSL handshake. The server gets no assurance that the client is who he or she purports to be. Client certificates provide that reciprocal assurance.
Why might the BYTE Site need to require that users present digital IDs? In commercial transactions, we'd like to know that you're entitled to use the credit-card number you give us. In public discussions, we'd like some protection against libelous statements made under forged identities. That scenario became real to me when DejaNews had to shut down the part of its service that enabled posting to Usenet. It's back now, but it's more cumbersome beca
use DejaNews has to route each posting through its From: address. Digital IDs will probably supplant that mechanism.
From Cookies to Certs
Even though one-way authentication has been around for several years, it's less widespread than you might think. Using Netcraft's measurement technology (
http://www.netcraft.co.uk/
), O'Reilly and Associates polled 648,613 Web servers. Only about 10 percent responded in secure mode. "Among these," said the O'Reilly/Netcraft report, "only 3239 [about 0.5 percent] offered a valid certificate signed by a trusted third party."
Reciprocal authentication
is even rarer because services that issue client certificates, and servers that know how to ask clients to authenticate themselves using certificates, are just now coming on-line. T
oday, a site that issues you access credentials likely does so by means of a cookie -- that is, a name/value pair sent from a Web server to your browser and stored in a file on your PC.
What's wrong with cookies? They can't guarantee either privacy or authentication. Say the BYTE Site issues Joe Smith an access cookie of the form: name=BYTE, user=Joe Smith/35428. Clearly, the idea here is that the site will check the value of the BYTE cookie in transactions with its users. But any other Web server to which Joe connects can also ask for his BYTE cookie! If Joe stores private data on our site, it won't be hard for others to find it. Also, we can't prove that statements made in Joe's name -- for example, newsgroup postings -- are attributable to Joe.
Digital IDs can improve matters considerably. One approach would be to issue certificates ourselves. For a target group of subscribers, a registration procedure might ask for your subscriber number and use it as proof of identity. Another approach would be t
o outsource the CA function to a service that would issue and manage "BYTE-brand" certificates.
Sioux Authentication
I installed Sioux on BYTE's Linux server, fired it up, and was immediately able to establish an SSL connection thanks to its built-in demonstration certificate. At start-up, though, the SSL_ClientAuth directive in Sioux's ssl.conf file is turned off, and Sioux does not require clients to present certificates. When I turned SSL_ClientAuth on, Sioux did ask for a digital ID. However, it wouldn't accept the client certificate I'd gotten from VeriSign, nor would it accept a different one from another CA, Nortel (
http://www.nortel.com/
). Finally, I discovered that client certificates from Xcert did work with Sioux.
What was different? Xcert's lead developer Pat Richard says the
re's an ambiguity in how to encode X.509 certificates, and that Xcert supports both interpretations.
How does the server read the fields of a client certificate? Sioux exports these as Common Gateway Interface (CGI) variables. Its built-in Python interpreter can straightforwardly access the certificate's data (see the listing
"Reading a Client Certificate with Sioux"
). So you could use CGI scripts to regulate access to areas of a site. A script might match the certificate's name and e-mail address against a database of registered users. Or it could just verify the identity of the certificate's signer. If you're issuing your own brand of certificates, that might be all you need to know. Because Sioux uses Python internally, there's no per-script process-creation overhead. Despite this best-case scenario, however, it would be expensive to run Python code every time a browser requested a page.
There's a faster, cleaner way. Using the SSL_Require directive, you can simply declare in
a configuration file that access to an area of your Web site requires a client certificate whose fields contain specified values. For example:
<directory /web/docs>
SSL_Require SSL_CLIENT_IO="BYTE"
</directory>
says that /web/docs is open only to browsers presenting BYTE-issued certificates. That's not enough, though. On whose authority will you accept the certificate's data as valid? After all, anyone can go to Xcert's site and create a client certificate whose fields say anything at all.
There has to be a way to trust only certificates issued by a particular CA, possibly your own. The situation is analogous to server authentication. The list of CA certificates preloaded in your browser enumerates the authorities whose server certificates you agree to accept. Similarly, in Sioux, you can install CA certificates that define the authorities whose client certificates your server will accept. In theory, I should have been able to install my own Xcert CA certificate -- that i
s, the certificate of the test CA I created at
http://www.xcert.com
-- and thereby accept only "BYTE-brand" client certificates issued by that CA.
In practice, I never got this to work. Should the CA certificate have been in Privacy-Enhanced Mail (PEM) rather than Distinguished Encoding Rules (DER) format? While sorting through the options, it all became a moot point.
Thawte Consulting (
http://www.thawte.com/
), Sioux's creator, transferred ownership of the product to C2Net Software (
http://www.c2.net/
), creator of another secure Apache derivative called Stronghold. C2Net intends to incorporate Sioux's best features -- embedded Python, GUI administration, and declarative certificate-based access filters -- into a version of Stronghold that may be available in a beta version by the time you read this. (Thawte, meanwhile, will focus on competing with VeriSign in the CA business.) The Sioux/Stronghold hybrid sounds promising, and I'm eager to try it.
Authentication with IIS
BYTE's official VeriSign-supplied server certificate lives on
http://www.byte.com
. That server runs NT 3.51 and IIS 1.0c, a combination that does not support client authentication. IIS 3.0, which is basically version 2.0 plus Active Server Pages, can
do client authentication, but only under NT 4.0. Microsoft's eagerness to make NT 3.51 obsolete strikes me as unseemly.
In IIS 3.0, a GUI application called Key Manager replaces the version 1.0 command-line tools keygen (which generates a key pair and a certificate-signing request) and setkey (which installs a signed certificate). I used Key Manager in conjunction with Xcert's public tools to install a server certificate on my test IIS 3.0 system. Then I used the IIS Internet Service Administrator to secure a virtual directory and to require client authentication for access to that directory.
Now or Later?
Solutions based on digital IDs are almost within reach. The supporting technologies, though raw and formative today, are evolving rapidly. They'll have to, because there's a huge burden of complexity attached to the use of digital IDs. Early adopters will shoulder more of that burden than stragglers. Is it worth the trouble? I expect it will be, but I'll admit that it's tempting
to wait until things work more smoothly.
TOOLWATCH
Xcert Demo CA
Internet:
http://www.xcert.com/
With the public CA tools at this site, you can generate the client
and server certificates you'll need to develop and test SSL-oriented
Web applications.
BOOKNOTE
Programming Python
by Mark Lutz
Publisher: O'Reilly and Associates
Internet:
http://www.ora.com/catalog/python/
Price: $44.95
A
comprehensive guide to Python, a powerful and increasingly popular
object-oriented scripting language.
Python code lists the values of Sioux's CGI variables, including the
fields of client and certificates:
vars = os.environ.keys()
vars.sort()
for env in vars:
print '\t<LI> <B>' + env + '</B>: ' + os.environ[env]
Here's an excerpt from the resulting HTML page:
SERVER_PORT 443
SERVER_SOFTWARE Sioux/1.0.1server
SSL_CIPHER EXP-RC4-MD5
SSL_CLIENT_C US
SSL_CLIENT_CERTIFICATE d5d4795a.0
SSL_CLIENT_CERT_END 970116032800Z
illustration_link (51 Kbytes)
Server authentication happens routinely, but client authentication is a new frontier.
photo_link (18 Kbytes)
Jon Udell (
judell@bix.com
) is BYTE's executive editor for new media.
Digital IDs
