It looks like there's some confusion about the Netscape security problem Ian Goldberg (iang@cs.berkeley.edu) and I found, as mentioned recently on cypherpunks. If we'd foreseen that such a silly bug would receive so much attention, I think we would've tried to prepare a more comprehensive description... But we didn't. Anyhow, let's see what I can clear up for you now. [Note: Ian isn't here right now, so he hasn't had a chance to look at this. Any errors are mine, any opinions are mine, etc.] In article <david-1909951219130001@192.0.2.1> from sci.crypt, David Sternlight <david@sternlight.com> wrote:
If the above is, in fact, accurate it appears to apply to previous versions of Netscape, not the 2.0 versions for which the public beta goes out next week.
We haven't tried it on v2.0, as we only have a copy of v1.1 right now. But the front-page New York Times article today said that the next version also has the same flaw, and that it'll be fixed before release. A Netscape official press release is available at http://www.netscape.com/newsref/std/random_seed_security.html Also our prototype code can be found at ftp://ftp.csua.berkeley.edu/pub/cypherpunks/cryptanalysis/unssl.c
In addition the flat statement that "keys can now be found in appx 1 min." is not, as it seems, a general one but (if one reads the details) requires a number of special assumptions, applies only to some machines, and applies only if one can develop certain collateral information.
You are partially correct. It all depends on the threat model. If the attacker has user-level access (e.g. an account) on the machine where you run Netscape, your encrypted sessions can be broken quickly. (Our tools took about 1 minute on 1 machine, but was just a proof of concept -- I believe the time could be significantly reduced, and automated completely.) This model is not entirely unreasonable IMHO. If the attacker is simply sniffing the wire somewhere between you and the https: server, and has no account on your machine, things are a bit more complicated. Ian & I are still discussing this case, but I'll mention a few of our observations: * the time, pid, and ppid are mixed together in such a way that there is certainly no more than 47 bits of entropy (which is a far cry from the 128 bits claimed for their commercial domestic version). * the attacker can guess the current time to within a few seconds easily. * maybe the attacker can get this down to about 10 msec uncertainty, possibly even less in some cases. * the ppid is often 1 (e.g. when you start up Netscape from a X-windows menu). * if not 1, the ppid is often just a bit smaller than the pid. * on personal workstations, the pid and ppid are often quite small. * one can remotely determine pid's by talking to sendmail on the attacked machine and bouncing mail -- the pid will usually be in the Message-ID. (if the attacker host runs sendmail, which is a usual case) because pids are assigned sequentially, this leaves very little uncertainty in Netscape's pid. * there's no notion of pid or ppid on MS-DOS: God only knows what Netscape does there. maybe it's just seeded from the time!! * the PRNG is never reseeded for the duration of a cached connection. While we don't yet know exactly how long it would take to break Netscape's PRNG in this threat model, I think it's clear that Netscape's current implementation is insufficient and insecure. You mention that our attack is only applicable to certain machines. You may well be correct -- this is one area where our experiments were still proceeding when the media descended on us today. <chuckle> Certainly the Solaris 2.0 and HP-UX versions of Netscape v1.1 are vulnerable: we tested them ourselves. Ian told me he got email from people who are trying unssl.c on other architectures, and apparently the SunOS 4.x.x version is vulnerable too (and tests of other machines are in progress). We don't know about e.g. PC's yet -- this is another area we were still working on. I will note that Netscape didn't try to claim that any version was safe from this flaw, for what that's worth... Hopefully this will be quickly fixed by Netscape, and then we can all stop worrying about it! :-) David Wagner, daw@cs.berkeley.edu, speaking {for,to} himself