Poor Richard 38
#038/13-Dec-99
POOR RICHARD'S WEB SITE NEWS
Geek-Free, Commonsense Advice on Building a Low-Cost Web Site
Editor: Peter Kent
Top Floor Publishing
http://PoorRichard.com/
Over 40,000 Subscribers in More Than 100 Countries!
SPECIAL EDITION!
THREE WEEKS UNTIL THE Y2K BROWSER BOMB
IMPORTANT --> THIS ARTICLE IS AVAILABLE ON THE WEB AT http://PoorRichard.com/y2k/
IN THIS ISSUE
- Introduction
- Summary
- Public Key Encryption
- Web Browsers and Public Key Encryption
- The Bug
- Who Will Be Affected?
- The EWS Browser Statistics Page
- My Store Logs
- Full Disclosure?
- Bomb, Bug, or Design?
- Merchants, What Can You Do?
- Can We Trust Software Developers With Our Lives?
- Why Do We Need Certification Authorities?
- The System is Broken
- Poor Richard's Web Site and Other Top Floor Books
- Book Reviewers Wanted
- Reading Back Issues
**** IF YOU FIND THIS NEWSLETTER USEFUL ... FORWARD IT TO FRIENDS AND COLLEAGUES ****
****************************************************sponsor****
Turn paper documents and faxes into electronic documents with Eastman Software Imaging for Windows Professional Edition(PRO)!
Purchase PRO for only $49.00 (regularly $89.00)!
Order your copy at: http://shop.eastmansoftware.com/imagepro/deploy/upgrade.htm
Use your scanner or fax machine to transform paper documents into electronic documents that you can view, edit and distribute. Eliminate the manual entry and re-entry, printing, copying and distribution of paper documents common to your day-to-day work.
****sponsor****************************************************
Introduction
This summer I stumbled across an important story related to a serious bug in the most commonly used Web browsers, a bug that is going to affect millions of online buyers and merchants, starting early in the morning on January 1st, 2000 ... less than three weeks from now. This is a Y2K bug, but in the last place you'd expect to find it -- in computer code that is three years old.
After the "Wall Street Journal" told me that yes, they would like the story, and would be happy to have me talk to one of their writers, but no, I couldn't write it, and no, I couldn't share a byline ... well, I thought, in that case I might as well break the story in my own newsletter!
Summary
This is rather a long report, so let me begin with a quick summary.
- Public-key encryption is a method used for securing the transmission of private data in Web browsers, and for the creation of digital signatures
- Web browsers contain libraries of certificates used to match against certificates passed from Web servers
- A significant number of browsers hold certificates that will expire at the end of this year
- On January the 1st, around 10% of buyers at Web stores may encounter problems due to expired browser certificates
- The browser problem is a "design bug," in the same way that other Y2K problems are design bugs. The programs are working the way they were designed to ... they just shouldn't work that way!
- Merchants can protect themselves to some degree by switching to Thawte certificates
- The entire certification system has broken down -- certificates are not required for encrypted transactions, nor do they "certify" most Web merchants.
Public Key Encryption
In order to understand what's going on, we need a quick description of how secure servers work. Secure Web servers use a system called "public-key encryption." Originally discovered, according to a recent article in "Wired," by British Intelligence -- but kept under wraps and rediscovered a few years later by American researchers -- public-key encryption is an amazing achievement of higher math. I regard it as magic, in fact, partly because my math skills are not sufficient to allow me to fully understand how such a system works. Nonetheless, I can explain in general, non-technical terms, how public-key encryption works. (If you already understand these basics, you may want to skip down to "The Bug," below.)
In public-key encryption you can encrypt and decrypt data -- that is, scramble and unscramble it -- using a matching pair of "keys," or codes. These keys are, in fact, long prime numbers. You take one of these keys, along with the information you want to encrypt, add a special algorithm, shake them all about, and you end up with encrypted data; a completely incomprehensible jumble of garbage. Now, take the encrypted data, the algorithm, and the _other_ key, mix 'em all together ... and, like magic, the information is unscrambled.
Now, here's the really odd thing. If you encrypt the message using one key, it can only be decrypted using the other key -- you cannot use the same key to both encrypt and decrypt. The implications of this are far reaching; modern e-commerce relies on this feature, in fact. It means you can both encrypt data for security reasons, and you can encrypt something in order to sign it -- to prove where it comes from.
The two keys are known as the private key and the public key. The private key -- often called the secret key -- is kept, well, secret. Yet the public key is handed out to anyone who wants it. Now, watch carefully as I perform this trick: I take the public key and use it to encrypt a message. Who can decrypt this message? Only the person with the private key. The message is completely secure, because the private key is closely held by a single person or institution. So if you ever want to send a secure message to someone, all you need to do is get his public key and use it to encrypt the message. The CIA could post its public key at its Web site, and its agents throughout the world could download the key, encrypt messages, and send them home ... and those messages would be completely secure. (In fact intelligence services _do_ use such techniques, though not quite as blatantly as posting the public key on their Web sites, perhaps.)
Another trick: This time I take the _private_ key and encrypt the message. Who can decrypt this message? Well, anyone who has the public key, and that could be a lot of people. The data is certainly not secure. But remember, a key can only decrypt a message created by the matching key. So if you can decrypt a message, you know it can only have been encrypted using the matching key. If the public key can decrypt a message, then, the message _must_ have been encrypted by the matching private key. And that's how digital signatures work. If you can decrypt the message with a public key, it has, in effect, been "signed" by whoever has access to the private key.
Web Browsers and Public Key Encryption
All this public/private key stuff is built into Web browsers and Web servers (since 1994 most popular browsers have had built-in encryption capabilities). A server has a certificate that identifies it to browsers. And browsers contain a small library of certificates that can be compared to a server's certificate to see if there's a match. A server's certificate may have been created by the server administrator, but there's a problem with that -- the certificate won't be recognized by most browsers. Although creating your own certificates may make sense in some cases -- for a private corporate network, for instance -- if you have a public Web store you can't use a "home-made" certificate, because your visitors' browsers will warn them that the certificate is not recognized. Rather, you have to buy a certificate from a certification authority (CA) that has an arrangement with Microsoft and Netscape to put a matching certificate in the browser. You'll probably buy the certificate from VeriSign or Thawte, the two major CAs, though there are several others.
Here's what happens when a browser visits a secure Web server. The Web server sends its certificate to the browser; that certificate has been signed using the private key that belongs to the CA that issued the certificate. The browser looks for a matching certificate in its library, takes the matching certificate's public key, and tries to decrypt the incoming certificate. If it can decrypt it, the two keys match, so the browser knows that the certificate is valid.
Now, when a buyer enters credit card information into a form at your store and sends the information, what happens? Well, along with the certificate came a public key, belonging to the store itself. The browser uses that key to encrypt the data in the form, then sends it back to the server. The server then uses the matching private key to decrypt the data and save it on the server's hard drive.
****************************************************sponsor****
Earn $$$ from your computer knowledge!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How often do you get asked for advice about computers?
Find out how you can earn from the help you provide.
Visit
http://www.joinhandtech.com/asp/jtr/default.asp?m2k=ss5815b
Join now and you can earn a $400 Technology Shopping Spree.
****sponsor****************************************************
The Bug
Now you understand how it's supposed to work, let's discuss what can go wrong. Let's say the Web server sends a certificate that the browser doesn't recognize. Either it's a certificate that is not in the browser's library of certificates ... or, more to the point, it's a certificate that _is_ in the list, but one that has expired. Certificates have a finite lifespan, a date after which the browser is going to assume the certificate is no longer valid. What will the buyer see? He'll see a message telling him that the server is sending an invalid certificate.
Let me be quite clear about this. The certificate issued to the Web server has a finite life -- one year, generally -- and has to be renewed each year. But more importantly, the matching certificate in the browser has a finite life, too. If, say, the VeriSign certificate in the browser has expired, the browser will display a warning message whenever a server sends a VeriSign certificate to the browser, even if that certificate is a valid, unexpired, certificate.
And if this occurs when a buyer is entering the checkout phase of a purchase, what will the buyer do? Will he think, "that's okay, it's just an expired certificate, I'll go ahead and buy anyway"? Or will the buyer be confused, concerned, worried? Will the buyer, who has quite likely only recently overcome his fears of online buying, leave the store without completing his purchase? There's a good chance that's just what he'll do.
So the big question is, when do these certificates, the ones in the browsers, expire? First, the good news. Most certificates held by browsers will not expire until well into the next century -- 2020 or later. The bad news is, though, that a significant number of older browsers have certificates that will expire ... you guessed it, on the last day of this year.
Who Will Be Affected?
The question is not whether this bug will hit (and I'll discuss whether this is really a bug at all in a moment), but how hard it will hit. The bug's out there, and it will come into play about three weeks from now. How much damage it will do is the difficult question.
First, let's consider _which_ browsers are affected. We'll just consider the two popular certificates, VeriSign/RSA (VeriSign, which is owned by RSA, administers certificates issued by RSA and itself) and Thawte. (Other CAs have an insignificant part of the market.)
VeriSign certificates in Netscape Navigator prior to version 4.06 will expire at the end of this year. Thawte certificates in Netscape Navigator versions prior to version 3 will also expire. Mark Shuttleworth, the founder of Thawte, told me that VeriSign were "caught napping," which is why they didn't get longer-term certificates into Netscape Navigator until much later than Thawte. He also admits that he now wishes he'd picked a later expiration date for the earlier browsers!
As for Internet Explorer, some versions do have old certificates -- Version 3 and earlier have the old certificates that will expire on January 1st. However, it's not an issue for merchants, because the browser won't inform the user with any kind of warning message. So we're only really concerned with Netscape Navigator.
---------------
I'm not entirely sure about the Internet Explorer problem. VeriSign says that _some_ versions of Explorer _will_ display a message box, specifically Internet Explorer 4.01 for Macintosh
---------------
The next question, then, is how many people this represents. I think we can get a reasonable idea of how many people currently have browsers that have the old VeriSign certificates. Let's look at a browser statistic site, and at my own store's logs.
The EWS Browser Statistics Page
While working on this article, I looked at the EWS Browser Statistics page (at http://www.cen.uiuc.edu/bstats/latest.html ). This page shows information about browsers that requested Web pages from the Engineering Workstations Server at the University of Illinois at Urbana-Champaign during the previous day (I saw the statistics for December 7th). The interesting thing about this site is that it has a special statistic; it shows the number of browsers that are "VeriSign Y2K-Ready." In other words, the ones that have VeriSign certificates that will _not_ expire at the end of the year.
According to the December 7th statistics, 38.1% of all the browsers were some flavor of Netscape Navigator, and of those, 73.7% were VeriSign Y2K ready; in other words, 26.3% of the Netscape browsers -- more than one in four -- are old versions that are _not_ Y2K ready. Which means that about 10% (26.3% of 38.1%) of all visitors to this site are using old VeriSign certificates.
My Store Logs
For another look at what may happen to Web stores, I picked my own Top Floor Publishing store ( http://TopFloor.com/ ). Each time someone places an order, the software identifies the type of browser the buyer is working with. So I checked just now, and discovered that my numbers are pretty close to the EWS numbers. Over the last month almost 11% of my customers were using Netscape Navigator versions that are not VeriSign Y2K Ready. Real numbers, from a real store, just a few weeks before January 1st.
The number I came up with, 11%, is the same as the estimate published by Thawte ( http://www.thawte.com/vs2000.html ). To be fair, I should mention that VeriSign claims the number is just 4% ... but based on my real-life numbers, and those from EWS, I find the 4% figure rather unlikely. Some estimates put the number of affected browsers as high as 25%, though I think that's rather unlikely, too. Ten or eleven percent looks about right to me.
In other words, it seems probable that on January 1st one customer in 10 or so entering a secure Web site using a VeriSign certificate is going to see a message warning them that the browser doesn't recognize the site. (If the site has a Thawte certificate, that number will probably be around one in twenty.) One customer in 10 or so will wonder what the message means, and will have to decide whether to leave the store or continue with the purchase. From the merchant's point of view that's very significant. It means the possibility of significant loss in sales, and extra customer-service costs dealing with questions.
Full Disclosure?
The two major certification authorities, VeriSign and Thawte, have handled the situation in very different ways. VeriSign is not saying much about it at all. On their front page they have a link titled "Prepare Your Site for 2000 and Beyond," but if you follow it you'll find this note: "After a comprehensive examination, we are confident that our services will remain unaffected by Y2K-related problems." I'm not sure what that means, but it certainly doesn't seem appropriate considering this browser problem. Dig deeper in this area of the site (but why bother if there are going to be no problems?), and you may run into this link: "Address Potential Root CA Certificate Rollover Issues with Your Server and Your End User's Browsers." This vague and confusing link is the one that you'd need to click on (but be unlikely to do so) if you were to learn about the browser problem. I'll save you the trouble of finding this, though; if you want to see what VeriSign has to say, here's the page: http://www.verisign.com/server/cus/rootcert/webmaster.html
I discussed the issue with a couple of VeriSign VPs this summer, and they told me that their main plan was to upgrade everybody's browsers (more specifically, to hope that Netscape ensured that everyone's browser was upgraded), so that by the end of the year the number of browsers with expired certificates would be negligible. Clearly they weren't successful -- I don't regard one user in ten as negligible. Even VeriSign's own number -- one in 25 -- might be regarded as excessive (and anyway, their number is almost certainly wrong).
Thawte, on the other hand, is quite open about the issue, and has been for many months. But then, they're in a good position. Although Mark Shuttleworth admitted to me that he'd made a mistake in creating a short-term certificate for use in the browser, he caught his mistake much sooner than VeriSign did. So on January 1st, the best certificate for a Web server to have, the one that will cause the fewest problems (5% rather than 10%), is a Thawte certificate. Thus full disclosure is clearly in Thawte's interest.
Bomb, Bug, or Design?
I've worked with software developers for almost 19 years, and long ago I realized that the term "bug" is rather subjective. Point out something that a program really shouldn't do, and a software developer may say to you, "that's not a bug ... that's the way we designed it." "Well," I used to say, "maybe you shouldn't have!"
I call these things "design bugs." At NCSA, the home of Mosaic, they had another term. Mosaic was the forerunner of Netscape Navigator, so some of the Netscape development team may remember this term. They called the stupid things that programs do, things they were originally designed to do, "bug-like features." In other words, "yes, we designed it this way ... but we know now it doesn't make sense and shouldn't have been done." The certificate-expiration problem is definitely a bug-like feature. It was designed into the programs -- but clearly shouldn't have been.
Strictly speaking, though, it's not a bug. A bug can occur at any time, yet this is a timed event; it will happen at the end of the year. It's actually what's known in the software business as a "bomb" -- something coded into a program that will cause a failure at a particular date and time. Bombs are hard to accidentally place into a program, though it does happen now and then. Generally, though, accidental bombs are timing related -- the event occurs after the program has been running for a number of hours or days. Creating a bomb that will go off on a particular date usually requires an intentional act, so bombs are often used by disgruntled employees who know their employment is likely to come to an end soon. In the case of the browser bugs, there was no malice intended -- so you might call this a "design bomb."
However, the term "Y2K bug" has entered the vernacular, and this browser problem clearly fits the description of a Y2K bug. All Y2K bugs were entered into the programs intentionally, remember ... the programmers just didn't think the date constraints mattered.
Already many in the business are saying that this is _not_ a Y2K bug. "The browser is behaving correctly," says the information at the Thawte site, for instance. "When the certificate authority root expires the browser should no longer trust it." That's quite correct. "This is not a software bug, or a date-processing bug," it continues, because "the certificate authority in each case explicitly chase (sic) the expiration date of 1999/12/31."
But it clearly is a bug. Surely nobody ever intended us to be in a situation in which one person in ten, a total of literally millions of people, should run into this problem. And although the CAs explicitly chose the expiration date, the founder of Thawte personally told me that the choice was a mistake. (Incidentally, dates in these certificates, even in the newer certificates, are two-digit dates; newer certificates use some two-digit years to specify dates in the 20th century, and some to specify dates in the 21st.)
If this is not a bug, then there's no such thing as a Y2K bug of any kind. The Y2K bug exists in programs that are behaving correctly, in the way they're intended to work ... it's just that, as with the browser bug, they weren't supposed to be still working!
Merchants, What Can You Do?
If you're a merchant, what can you do to alleviate this problem? (There's no way to eradicate it). You need to switch to a Thawte certificate. (http://www.Thawte.com/.) They're $125 (cheaper than a VeriSign certificate), but will probably have half as many problems as a VeriSign certificate. (So do the math and figure out if he cost outweighs the hassles.)
Of course you may have no control over the certificate used by the company hosting your e-commerce system. But at least you can encourage them to switch; send them this article if you wish.
Can We Trust Software Developers With Our Lives?
There's a larger issue here. Software is becoming pervasive. Every aspect of our lives is being taken over by software, and, by extension, programmers. Can we trust them to do a good job?
Consider this. We've heard a lot about the Y2K problem over the last few years. Everyone in the software business knew the term long ago, well before the days of the Web. Among the general public, Y2K problems are regarded as "legacy" problems, time bombs coded into programs decades ago. But this Y2K problem was caused by decisions made just three years ago! If the people running the software business -- running our lives -- cannot see three years ahead ... just what can they see?
Let me put it another way. Do we really want software driving our cars and flying our planes? (Oops, too late!)
Why Do We Need Certification Authorities?
There are a couple of interesting twists in this story. The first concerns the purpose of certification authorities; few Web users understand the whole purpose of the certification system. Remember, what the certificate comes down to is really just a couple of prime numbers, the private and public keys. It's not the algorithm used to manipulate the numbers; that's built into the browser and server software. It's the numbers themselves.
Also, note that a Web-server administrator can create his own certificates. He doesn't have to go to a CA to get a certificate. Technically speaking, then, there is no need for a CA in order to carry out the secure transmission of data across the Web. We don't need VeriSign or Thawte as part of the process in order to secure credit-card data as it's sent across the wires.
However, creating a certificate doesn't do a Web store any good, because if you create your own certificate rather than buy it from VeriSign or Thawte, your customers' browsers won't recognize it. The user can choose to go ahead and carry out the transaction, and the transaction will be secure. But he'll see a message warning him that the browser doesn't recognize the certificate, a warning that will drive away many buyers.
The obvious question is, then, "Why do we need certification authorities?" We don't need them to secure online transmission of data, after all. When a merchant buys a certificate, he's not buying it so that he can process orders securely. Rather, he's buying it so that his buyers won't see a warning message when they try to process orders securely (though to be honest most merchants don't really understand this).
But a CA doesn't simply issue certificates, it's supposed to investigate the person or organization that's buying the certificate, to ensure they are who they say they are. The real point of the process is that when your browser looks at the certificate and checks its validity, it's telling you that "VeriSign (or Thawte or whoever) has investigated this company, and has issued a certificate saying that they check out okay."
That's the purpose of the whole certification process -- not to enable encrypted data transmissions, but to certify the company that bought the certificate.
The System is Broken
And that's where the system has completely broken down. Let's say you sign up to run a store with an e-commerce hosting company such as Yahoo or BigStep, or any one of dozens of other companies ... a company that has shopping-cart software you can use to run your own Web store. Whose certificate are you going to be using? In the case of Yahoo or BigStep, and in most other cases, you'll use the hosting company's certificate.
Let's think this through. VeriSign certified Yahoo; the certificate tells the browser that Yahoo is who it claims to be. Yahoo then uses that certificate to process transactions through, let's say, "Fred's Stuff and Junk store." VeriSign has not investigated Fred or his store; nor has Yahoo. So where does that leave us? With a certificate that isn't needed to process transactions, and that only _appears_ to certify the storeowner ... but in fact doesn't, because VeriSign has never heard of Fred.
Big weakness, eh? Officially VeriSign does not allow the sharing of certificates. Yahoo is not allowed to share the certificate with Fred, Fred has to get his own. (Thawte allows the sharing of certificates, though they discourage it.) But VeriSign isn't enforcing its own regulations. I chatted with some VPs at VeriSign a few months ago, and was told that no, Yahoo shouldn't be doing that, and that VeriSign "reserved the right to take legal action against companies that share their certificates." As far as I know, VeriSign has taken no action against anyone ... at the time of writing the sharing of certificates is a common practice.
The certification system is currently an unnecessary complication and expense. It makes little sense, because the users don't understand that it even exists, and it doesn't do what it's supposed to do. In other words, the certification process has almost completely broken down.
Poor Richard's Web Site and Other Top Floor Books
Top Floor Publishing now has five books in print:
Poor Richard's E-mail Publishing
http://PoorRichard.com/email/
Poor Richard's Web Site
http://PoorRichard.com/
Poor Richard's Internet Marketing and Promotions
http://PoorRichard.com/promo/
The CDnow Story: Rags to Riches on the Internet
http://TopFloor.com/cdnow/
MP3 and the Digital Music Revolution: Turn Your PC into a CD-Quality Jukebox -- http://TopFloor.com/mp3/
Order direct from the publisher, and you'll get a 100%, 1-Year Guarantee. If you feel the book wasn't worth the money, send it back for a refund!
And remember, these books are discounted at the Web site, and you pay just one shipping cost regardless of how many books you buy!
Book Reviewers Wanted
Do you review books for newspapers, magazines, newsletters (electronic or paper), Web sites, or other media spots? If so, perhaps you'd like to review Top Floor Publishing's latest book, "Poor Richard's E-mail Publishing." Or perhaps you'd like to review one of the other books I mentioned above?
Contact my Marketing Director, Missy Derkacz, at reviews@TopFloor.com. Include your full mailing address, the name of newspaper/magazine/whatever in which the review will appear and the probable date of publication, and the editor's contact information.
Reading Back Issues
If you need to refer to back issues of this newsletter -- and search the archives -- you can find them at the following location:
http://PoorRichard.com/newsltr/
-------------------------------------------------------------
(c) Copyright 1999, Top Floor Publishing
All Rights Reserved
-------------------------------------------------------------If you like this newsletter, PLEASE FORWARD IT to friends and colleagues!
Please retain this copyright and subscription information; you may want to remove your e-mail address from below.
It may be posted, in it's entirety or partially, to newsgroups or mailing lists, as long as the copyright and subscription information remains.
