[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Assessing Netscape Commerce Server Risk



Would anyone care to critique this assessment?

>Q:  What is the risk of implementing the Commerce Server without waiting for
>the Oct. 9 patch (which fixes the randomness problem with the server's
>public/private key pair)?

>A: The exposure is essentially this: if someone were to make a concerted
>attack on your public/private key pair, they might be able to discover your
>private key.  Combined with net eavesdropping this would allow interception
>and decrypting of SSL-encrypted traffic to your Commerce Server, and
>combined with IP address and DNS domain impersonation would allow someone
>to masquerade as your server.
>
>I would characterize this risk as low to moderate, with the higher risk
>only applying if your Commerce Server is handling larger financial
>transactions or extremely sensitive information.
>
>The time required for an attack on your key pair depends on how close the
>attacker can come to guessing exactly when your key pair was generated, and
>what the pid/ppid were for the key generation program at the time the key
>was generated, as well as how fast the attacker can generate candidate key
>pairs.  Since the time and pid/ppid are probably guessable only within
>broad limits (e.g., within a few days for the time), and generating key
>pairs takes on the order of a second or so, the estimated attack times are
>much longer than the attack times for SSL messages.  I believe Netscape has
>published estimates like 60 days or so to crack a key pair; even if those
>estimates are too high by factors of two or three the times are still
>comparable to the time until the patch is available.
>
>So if you're really concerned you can certainly eliminate the risk by
>shutting down SSL-secure services until you get the patch; however I'd
>weigh that against the downside of not having those services accessible.
>
>P.S. If you do continue running your Commerce Server with SSL, one simple
>thing that might help thwart attacks is to do a "touch" on your server key
>file and server certificate file (or copy them somewhere and then copy them
>back) to update the date/time modified on the files.  This eliminates one
>possible clue as to when the key pair was generated.

_________________________________________________
Dave Millar  University Information Security Officer
3401 Walnut St., Suite 265C
Philadelphia, PA 19104-6228
University of Pennsylvania
For security matters:  [email protected] (read by Data Admin. staff)

Other matters: [email protected]
voice: (215) 898-2172
fax: (215) 898-1729
For PGP 2.6 Public key: http://www.upenn.edu/security-privacy/
PGP Fingerprint:   28 FB 09 DC C7 96 C2 53  1A B8 BE 3B 73 32 46 4C