This newsletter is not sent unsolicited. See the end of this
message for more info (including subscribe/unsubscribe info).

   Geek-Free, Commonsense Advice on Building a Low-Cost Web Site

       Editor: Peter Kent
         Top Floor Publishing

        Over 40,000 Subscribers in More Than 100 Countries!




   ~~~ IN THIS ISSUE ~~~

   ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~



   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

   ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

   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:
   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.

   {{ 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

   * 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.

   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.
   Join now and you can earn a $400 Technology Shopping Spree.

   {{ 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

   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

   --> 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

   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

   {{ 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

   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

   Poor Richard's Web Site

   Poor Richard's Internet Marketing and Promotions

   The CDnow Story: Rags to Riches on the Internet

   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
   [EMAIL PROTECTED] 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


  (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.
  This newsletter is not sent unsolicited. All the e-mail
  addresses in our database have been submitted to us for
  inclusion. If you received this message and you haven't
  subscribed, a friend or colleague may have forwarded it to

  You are currently subscribed to prwebnews as: 

  To unsubscribe, forward this message to [EMAIL PROTECTED]

  To subscribe, send a blank e-mail message to

  To change your subscription address, unsubscribe by forwarding
  this message to [EMAIL PROTECTED], and then subscribe from 
  your new email account by sending a blank e-mail message to

  To read earlier issues of this newsletter, go to 

  To contact a real live human being (the above addresses go to
  mail-handling software), contact [EMAIL PROTECTED]

  For information about advertising in this newsletter, visit 
  http://www.poorrichard.com/newsltr/advert.htm or email 

Reply via email to