[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Long] A history of Netscape/MSIE problems
I've been putting together a writeup on problems in web browsers, mainly the
history of the Netscape RC4/40 break, random number bugs, and problems with
Java, as part of a longer paper I'm doing on crypto from a non-US perspective.
A lot of the information in this section of the paper has come from this list,
so I thought I'd post it for comment and in case anyone found it interesting
(please don't post it to web sites or anything until the paper is actually
published). If anyone has anything to add, corrections to make, etc, please
let me know.
Peter.
The Netscape SSL Break and its Implications
-------------------------------------------
The Secure Socket Layer (SSL) protocol, after a somewhat shaky start (version 1
was broken within 10 minutes of being unveiled [Hallam-Baker 1996]), and an
attempt by Microsoft to promote a similar but competing protocol [Benaloh
1995], has more or less edged out any other protocols to become the standard
for securing HTTP sessions (an overview of SSL and various other proposed WWW
security mechanisms is given in [Reif 1995a]). SSL uses a combination of RSA
and, usually, a proprietary (until it was reverse-engineered, of which more
later) algorithm called RC4 to provide confidentiality, data integrity, and
authentication. Since it was built into what was by far the most popular web
browser, and because of Netscape's policy of giving away the software, it
immediately gained widespread popularity. No details on RC4 were published,
but the fact that it was designed by a very good cryptographer was enough to
reassure most people. RC4 is used in dozens of commercial products including
Lotus Notes, a number of Microsoft products such as Windows for Workgroups,
Windows 95, Windows NT, and Access, Apple's AOCE, and Oracle Secure SQL.
The main criticism of SSL (apart from a few protocol flaws which were fixed in
later versions) was the fact that RC4 used a key of only 40 bits, making it
susceptible to a brute-force attack. The reason for the 40-bit key and
(according to RSADSI, the company that developed RC4) the reason why details on
it were kept secret was that these conditions were required under an agreement
between the Software Publishers Association (SPA) and the US government which
gave special export status to the RC4 algorithm and a companion algorithm
called RC2. Implementations of RC2 and RC4 which are restricted to a 40-bit
key get automatic export approval provided the implementations work correctly
with a set of test vectors supplied by the NSA. Provided the results are as
expected, export approval is granted within a week.
The weakness of the encryption in US-exportable SSL implementations even led
the French government, which normally bans all non-government-approved use of
encryption (the "decret du 18 avril 1939" defines 8 categories of arms and
munitions from the most dangerous (1st category) to the least dangerous (8th
category), the "decret 73-364 du 12 mars 1973" specifies that encryption
belongs to the second category, and the "loi 90-1170 du 29 decembre 1990"
states that use of encryption equipment must be approved by the French
government), to approve the use of Netscape in France [Vincent-Carrefour 1996],
presumably because the French government has no problems in breaking it.
The first step in attacking SSL was to find out how RC4 worked. Since it was
in widespread use, it was only a matter of time before someone picked the code
apart and published the algorithm. RSADSI sell a cryptographic toolkit called
BSAFE [BSAFE 1994] which contains RC4, and this seems a likely source for the
code (the Windows password encryption code is also a good source, and the
algorithm can be extracted in an hour or two). The results were posted to
mailing lists and the Internet [Anon 1994a]. Someone with a copy of BSAFE
tested it against the real thing and verified that the two algorithms produced
identical results [Rescorla 1994], and someone else checked with people who had
seen the original RC4 code to make sure that it had been (legally)
reverse-engineered rather than (illegally) copied [Anon 1994b].
The RC2 code was disclosed in a similar manner in 1996, but after problems with
legal threats during the RC4 disclosure process it was handled more formally:
First an RC2 implementation was reverse-engineered [Anon 1996], then a
specification for the algorithm was written based on the reverse-engineered
code [Gutmann 1996], and finally a new implementation based on the
specification was written by someone who had never seen the reverse-engineered
RC2 code [Vogelheim 1996]. No legal threats were ever issued over RC2.
The RC4 code was immediately subject to intense analysis in various
cryptography-related fora. RC4 has two parts, the initialization phase, and
the random number generation phase used for the encryption itself. An array is
initialized to be a random permutation using the user's key. The random number
generator then mixes the permutation and reports values looked up
pseudorandomly in that permutation.
Among various RC4 problems which were discussed are that the likelihood that
during the initialization phase small values will remain in small positions in
the initial permutation is too high; user keys are repeated to fill 256 bytes,
so 'aaaa' and 'aaaaa' produce the same permutation; results are looked up at
pseudorandom positions in the array, and if some internal state causes a
certain sequence of positions to be looked up, there are 255 similar internal
states that will look up values in the same sequence of positions (although the
values in those positions will be different), from which it can be shown that
cycles come in groups of 2^n, where all cycles in a group have the same length,
and all cycles are of an odd length * 256 unless they are in a group of 256;
there is a bias in the results so that, for example, the pattern "a a" is too
likely and the pattern "a b a" is too unlikely, which can be detected only
after examining about 8 trillion bytes; the internal state is not independent
of the results, so that with a given result there are two patterns in the
internal state that appear 1/256 times more often than they ought to; at least
two seperate methods exist for deducing the internal state from the results in
around 2^900 steps; and under certain special circumstances the initial byte of
the pseudo-random stream generated by RC4 is strongly correlated with only a
few bytes of the key.
All of these "weaknesses" except for the last one are purely theoretical in
nature, and even the last one can only occur under special circumstances (it
doesn't affect SSL implementations since they hash the key with MD5 rather than
using it directly, which avoids the problem). Overall, the cryptographic
community agreed that RC4, when used correctly, was a sound cipher.
Unfortunately, due to the US export restrictions, RC4 couldn't be used
correctly. Although Netscape negotiated a 128-bit key to protect each session,
it sent 88 of those 128 bits in the clear so that only 40 bits of the key were
actually kept secret. Now that RC4 was known, SSL became a prime target for
attack. An initial attempt at breaking RC4 was made in July 1995 using
encrypted data from a Microsoft Access database [Back 1995a]. This attempt
involved 89 contributors and took about a week using idle computing time on
workstations and PC's, with around 80% of the work being done by the top 19
contributors. Due to logistical problems, human error, and buggy software, the
attempt ultimately failed, but the stage had been set for an attack on SSL. On
14 July 1995, an SSL challenge message containing an encrypted (fake) credit
card order transmitted to one of Netscapes own computers was posted to mailing
lists and the Internet by Hal Finney [Finney 1995a]. The challenge message was
independantly broken by two groups, the first to announce success in breaking
it was a French researcher using idle time on a collection of 120 computers and
workstations over 8 days [Doligez 1995a] [Doligez 1995b]. The 40-bit secret
part of the key was 7E F0 96 1F A6, and was found after scanning just over half
the key space. The average search speed was about 850,000 keys/s, with a peak
of 1,350,000 keys/s. A second group had broken it two hours earlier, but
announced their success a day later [Back 1995b]. The event immediately
attracted international media attention, including newspaper, radio, and
television coverage (although many reports were rather garbled) in France
[Munger 1995], Germany [Reif 1995b], Japan [NewsBytes 1995], the UK [Arthur
1995], and the US [Beck 1995] [Sandberg 1995].
A second challenge was posted on 19 August 1995 [Finney 1995b] and an attack by
a `Brute Squad' of 201 Internet-connected volunteers began at 1800 GMT on 24
August 1995. The attack involved greatly improved software with automatic
communication between client workstations attacking the encryption and a
central server which doled out sections of keyspace to search [Brooks 1995].
This setup took 31.8 hours to find the key, 96 36 34 0D 46. Congestion on the
server being used to coordinate the attack meant that most of the machines
involved were idle for perhaps 3/4 of their available time, so in theory the
attack could have been completed in only 8 hours. Both the client and server
software was continually upgraded during the duration of the attack.
The attacks, which used only unused processing capacity on the machines, were
essentially "free", and could easily be mounted using the spare processing
capacity available in companies, businesses, universities, and foreign
governments. By breaking a brute-force attack into a number of independant
sections, as many machines as are needed can be applied to the problem, so that
each doubling of the amount of hardware applied to the problem halves the time
required to find the solution. Although the total investment will have
doubled, the cost per recovered key is kept constant since twice as many keys
can now be found in the same time.
Another possibility which has been suggested is the creation of an RC4-breaking
screen saver for networked Windows machines which performs key searches during
the (often prolonged) periods in which machines are left idle. One experiment
in performing this kind of attack took 2 weeks using relatively slow 486/50's
and Sparc 20's, with noone the wiser that the machines were being used
overnight for this purpose [Young 1996]. Another attack involved a networked
Windows screen saver where the client software was activated whenever a machine
was otherwise idle and communicated its results to a central server on a
network with around 100 PC's. By now, breaking the Netscape encryption had
become a kind of processor benchmark, with one manufacturer rating the speed of
their system based on how long it took to break RC4 - 8 hours on one computer
[ICE 1996].
Further improvements to the attack were proposed. The most important one was
to move from attacking one message at a time to attacking entire collections of
messages. Instead of generating a key and testing it against a single message,
it could be tested against 100 messages, so that in average one key could be
found in 1/100th the time it took for a single message. Unfortunately in the
case of SSL this wasn't possible, since although only 40 bits of key are kept
secret, there are still a total of 128 unique key bits for each message, making
it impossible to attack more than one message at a time. In effect the
remaining 88 bits of key act as a `salt' in the same way the Unix password salt
works. However a more simplistic implementation which uses only 40 bits of key
could be attacked in this manner.
The attacks on RC4 are a prime example of a publicity attack. They were
carried out by volunteers using borrowed machine time, noone (apart from
Netscapes stock prices) was harmed, and they achieved a great deal of
publicity. The intended goal - of proving that the restricted encryption
allowed by the US government could be broken - was achieved. This fuelled
intense debate within the US about the need to lift the export restrictions in
order to facilitate electronic commerce. Virtually every article covering the
encryption debate would eventually refer to the ease with which the 40-bit keys
of the form used in SSL could be broken (see for example [Ante 1996]). The
fact that it was completely uneconomical to mount a criminal attack on 40-bit
SSL keys was mostly ignored (except in Netscape press releases). The
enthusiasm for Internet commerce, especially commerce protected by SSL, was
severely dented, and companies began to adopt a more cautious attitude in
deploying commercial services over the net.
[Anon 1994a] `David Sterndark' (an alias), "RC4 Algorithm revealed", posting to
sci.crypt newsgroup, message-ID <[email protected]>, 14 September
1994.
[Anon 1994b] Anonymous, "`Alleged RC4' not real RSADSI code", posting to
sci.crypt newsgroup, message-ID <[email protected]>, 25
September 1994.
[Anon 1996] Anonymous, "RC2 source code", posting to sci.crypt newsgroup,
message-ID <[email protected]>, 29 January 1996.
[Ante 1996] Spence Ante, "Everything You Ever Wanted To Know About Cryptography
Legislation. . .(But Were Too Sensible to Ask)", PC World, May 1996.
[Arthur 1995] Charles Arthur, "Internet's 30bn Pound Secret Revealed", UK
Indpendent, 17 August 1995.
[Back 1995a] Adam Back, "Announce: Brute force of RC4, 40 bits all swept",
posting to sci.crypt newsgroup, message-ID <[email protected]>, 20 July
1995.
[Back 1995b] Adam Back, "Another SSL breakage...",. posting to cypherpunks
mailing list, 17 August 1995.
[Beck 1995] Alan Beck, "Netscape's Export SSL Broken by 120 Workstations and
One Student", HPCwire, 22 August 1995.
[Benaloh 1995] Josh Benaloh, Butler Lampson, Daniel Simon, Terence Spies, and
Bennet Yee, "The Private Communication Technology Protocol (PCT)", Microsoft
Corporation, October 1995.
[Brooks 1995] Piete Brooks, "Cypherpunks `brute' key cracking ring",
http://www.brute.cl.cam.ac.uk/brute/.
[BSAFE 1994] BSAFE 2.1 software, RSA Data Security Inc, 1994.
[Doligez 1995a] Damien Doligez, "SSL challenge -- broken!", posting to
sci.crypt newsgroup, message-ID <[email protected]>, 16 August
1995.
[Doligez 1995b] Damien Doligez, "SSL challenge virtual press conference",
http://pauillac.inria.fr/~doligez/ssl/press-conf.html.
[Finney 1995a] Hal Finney, "SSL RC4 Challenge", posting to sci.crypt newsgroup,
message-ID <[email protected]>, 14 July 1995.
[Finney 1995b] Hal Finney, "SSL Challenge #2", posting to cypherpunks mailing
list, message-ID <[email protected]>, 19 August 1995.
[Gutmann 1996] Peter Gutmann, "Specification for Ron Rivests Cipher No.2",
posting to sci.crypt newsgroup, message-ID <[email protected]>, 11
February 1996.
[Hallam-Baker 1996] Phill Hallam-Baker, "A problem with Navigator's cache
-Reply", posting to www-security mailing list, 25 August 1996.
[ICE 1996] Integrated Computing Engines, "MIT Student Uses ICE Graphics
Computer To Break Netscape Security in Less Than 8 Days", 10 January 1996.
[Munger 1995] Benoit Munger, "Cachez ces mots que je ne saurais lire", Le
Devoir, 28 August 1995.
[NewsBytes 1995] "Netscape Encrypted Data Cracked", NewsBytes, Tokyo, Japan, 18
August 1995.
[Sandberg 1995] Jared Sandberg, "French Hacker Cracks Netscape Code, Shrugging
Off U.S. Encryption Scheme", The Wall Street Journal, 17 August 1995, p.B3.
[Reif 1995a] Holger Reif, "Netz ohne Angst: Sicherheitsrisiken des Internet",
c't Magazine, September 1995, p.174.
[Reif 1995b] Holger Reif, "Peinliche Panne: Netscape gibt ernsthafte
Sicherheitslu"cken zu", c't Magazine, November 1995, p.26.
[Rescorla 1994] Eric Rescorla, "RC4 compatibility testing", posting to
cypherpunks mailing list, message-Id <[email protected]>, 13
September 1994.
[Trei 1995] Peter Trei, "Netscape's SSL security has been compromised", posting
to comp.security.misc newsgroup, message-ID <[email protected]>, 16
August 1995.
[Vincent-Carrefour 1996] Jacques Vincent-Carrefour, "Autorisation de fourniture
et d'utilisation generale de moyens de cryptologie No.2500", 509/DISSI dossier
numero 950038, 7 November 1995.
[Vogelheim 1996] Daniel Vogelheim, "RRC.2 implementation available", posting to
sci.crypt newsgroup, message-ID <[email protected]>, 19 February
1996.
[Young 1996] Eric Young, "Bank transactions on Internet", posting to
cypherpunks mailing list, message-ID
<Pine.SOL.3.91.960409104403.28771C-100000@orb>, 9 April 1996.
(In)Secure Internet Electronic Commerce
---------------------------------------
After the RC4 attacks, researchers looked for other weaknesses in Netscape. In
September 1995 it was discovered that Netscape didn't check the amount of input
it was fed, leading to internal buffers being overrun [Green 1995] [Neumann
1995]. This bug also existed in other browsers such as Mosaic and IBM's
WebExplorer. By carefully adjusting the data fed to the browser, it was
possible to force a victims PC to execute arbitrary code simply by selecting a
URL. This problem has occurred in the past in a number of other programs such
as fingerd (where it was exploited by the Internet worm [Spafford 1988]), the
CERN and NCSA httpd's (as explained below in the section [!!!!]), and recently
splitvt, syslog, and mount/umount, leading one exasperated mailing-list
moderator to wonder how many more times he'd see this problem [Bloodmask 1996].
The flaw in question can be exploited by ensuring that the code to be executed
is located in the URL at a point where it overflows the end of the buffer. A
URL can contain almost any data value except for a few characters which have
special significance and a binary zero, a restriction which can easily be
bypassed by selecting alternative encodings for any instructions which cause
problems. The browser stack looks as follows:
[Diagram: URL buffer, other data, callers saved program counter]
It is therefore possible, by making the URL long enough to overwrite the other
data and saved program counter, to force a jump to an attackers code rather
than returning to the calling routine, allowing an attacker to force the
execution of arbitrary code on the victims machine. Although this exploit is
machine and browser-specific, by targetting the most common architecture
(Windows on an Intel processor) and browser (Netscape), a reasonable chance of
success can be obtained.
At about the same time the stack overwrite problem was discovered, a basic flaw
was found in Netscape's SSL implementation which reduced the time to break the
encryption from hours to minutes. Despite an existing body of literature
covering the need for carefully selected random-number generation routines for
cryptographic applications [Eastlake 1994] [IEEE 1995] [Robertson 1995], one of
which even included ready-to-use code [Plumb 1994], Netscape used fairly simple
methods which resulted in easy-to-guess encryption keys [Goldberg 1995]
[Goldberg 1996]. It was found that, under Unix, Netscape used a combination of
the current time in seconds and microseconds and the process ID of the current
and parent process to initialise the random number generator which produced
master encryption keys. The time can be determined to a reasonable degree of
accuracy from the message being sent, the process ID's can be determined using
standard Unix utilities (by people using the same machine that Netscape is
running on), or by using other tricks such as the fact the an approximate
process ID can often be obtained by observing the output of other
network-related programs on the machine, and the parent process ID is often 1
(for example when Netscape is started from an X-windows menu) or close to the
process ID. Under Windows the implementation was similarly flawed.
The resulting number of values to search are smaller than the number of
combinations in a 40-bit key, and much smaller than the number of combinations
in the 128-bit key in the export-restricted version. Since Netscape never
reseeds its internal random number generator, subsequent connections are
relatively easy to break once the first one is broken. The researchers who
discovered this problem released a program, unssl [unssl 1995] which would
break Netscape's encryption (both the weak exportable version and the strong
export-restricted version) in about a minute on an average workstation.
Although one of the researchers classed it as "a silly bug", it received large
amounts of media attention, including front-page coverage in the New York Times
[Markoff 1995] and coverage in the Wall Street Journal [Sandberg 1995] and
Daily Telegraph [Uhlig 1995].
Attempts to fix this problem introduced yet more problems. Under Windows the
browser and server code, which appear to share the same random number code,
don't close some of the file handles they use. While this has no serious
effect on the client software (which doesn't run over extended periods of
time), it does effect the server, which after a period of time runs out of file
handles so that a number of calls related to gathering random data (some of
them not apparently file-related) quietly fail, significantly weakening the
random-number generation process [RingZero 1995]. The problem of insecure
random number generation was not unique to Netscape, and has in the past beset
XDM (which generates weak xauth keys), Netrek (a network game which generates
guessable RSA private keys), an earlier version of the SecuDE security toolkit
(which again generated guessable RSA keys), and Sesame (a european Kerberos
clone) which uses it to generate DES keys.
Significant security holes are also opened up through the use of Java, which
allows arbitrary programs downloaded from the net to run in a (supposedly)
controlled environment on a host PC. By breaking out of this controlled
environment, Java applets can act as trojan horse programs on the PC, bypassing
normal security measures. The consequences of these security problems have
been widely reported and include the destruction of data [Clark 1996], the
ability to access arbitrary files on the system [Felten 1996b], the ability to
forward sensitive information to arbitrary machines on the net (bypassing
firewalls and similar measures, since the "attack" comes from a trusted machine
inside the security perimeter) [Williams 1996] [Markoff 1996], or even run
arbitrary native code on the machine [Felten 1996a] [Hopwood 1996] [Kennedy
1996]. This last class of flaws are the most serious, since they allow any
code to be executed on a victims machine. The problem was in the class loading
code for the browser and affected all then available browsers rather than just
Netscape, and could be carried out simply by a victim viewing a web page
containing the hostile Java applet.
Java problems can be combined with other attacks such as DNS spoofing (in which
a fake address for a target machine is advertised), allowing a Java applet to
connect to a normally disallowed target machine since the Java security manager
thinks it is connecting to a safe system [Mueller 1996]. Other problems are
less subtle, and can crash the browser (and, under some versions of Windows,
the operating system as well) simply by connecting to a web page [Ref:
Browser-crashing pages]. One report comes to the conclusion that "because of
the wonderful power of the Java language, security problems are likely to
continue" [Neumann 1996].
These problems are not unique to Java. Microsoft's ActiveX has experienced
similar troubles, exemplified by a sample application which shuts down the
machine, and even turns off the power on systems which support this
functionality [McLain 1996]. The problems extend beyond Java and ActiveX to
other kinds of embedded executable content as well. For example the ability to
embed macros in documents viewed and downloaded by a browser, in combination
with security holes in the browser, allows an attacker to execute arbitrary
code on a victims system whenever they view the attackers web page [Felten
1996c]. Although this was subsequently fixed, the solution was to issue
warnings for all local files as well as remote downloads, so that after the
first dozen or so messages the user was likely to simply automatically click
"OK" whenever another warning popped up [Walsh 1996]. In addition a hostile
application could access the Windows registry (the system-wide database of
configuration options) to quietly disable the warnings. This creates a nice
niche for "espionage-enabling" viruses which disable or patch various security
features in operating systems or application software to allow later attacks.
At least one security organisation already uses such a program, a modified
stealth virus, for this purpose.
-> Mention that these are all seperate problems, not the same ref over and
over.
[Clark 1996] Don Clark, "Researchers Find Big Security Flaw In Java Language"
The Wall Street Journal, 26 March 1996, p.B4.
[Bloodmask 1996] `Bloodmask', "Vulnerability in ALL linux distributions",
posting to linux-alert mailing list, 30 July 1996.
[Eastlake 1994] Donald Eastlake, Stephen Crocker, Jeffrey Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[Felten 1996a] Ed Felten, "Security Flaw in Netscape 2.02", Risks-Forum Digest
Vol.18, Issue 13, 17 May 1996.
[Felten 1996b] Ed Felten, "Java security update", Risks-Forum Digest, Vol.18,
Issue 32, 13 August 1996.
[Felten 1996c] Ed Felten "Internet Explorer Security Problem", Risks-Forum
Digest, Vol.18, Issue 36, 21 August 1996.
[Goldberg 1995] Ian Goldberg, "Netscape SSL implementation cracked!", posting
to cypherpunks mailing list, message-ID:
<[email protected]>, 18 September 1995.
[Goldberg 1996] Ian Goldberg and David Wagner, "Randomness and the Netscape
Browser", Dr.Dobbs Journal, January 1996, p.66.
[Green 1995] Heather Green, "Netscape Says Hackers Uncover 3rd Flaw in Its
Internet Software", The New York Times, 25 Sep 1995.
[Hopwood 1996] David Hopwood, "Another Java security bug", posting to
comp.lang.java newsgroup, message-ID <[email protected]>, 2 June 1996.
[IEEE 1995] IEEE P1363 Appendix E, "Cryptographic Random Numbers", Draft
version 1.0, 11 November 1995.
[Kennedy 1996] David Kennedy, "Another Netscape Bug US$1K", Risks-Forum Digest,
Vol.18, Issue 1422, May 1996.
[Markoff 1995] John Markoff, "Security Flaw Is Discovered In Software Used in
Shopping", The New York Times, 19 September 1995, p.A1.
[Markoff 1996] John Markoff, "New Netscape Software Flaw Is Discovered", The
New York Times, 18 May 1996, p.31.
[McLain 1996] Fred McLain, "ActiveX, or how to put nuclear bombs in web pages",
http://www.halcyon.com/mclain/ActiveX/.
[Mueller 1996] Marianne Mueller, "Java security", Risks-Forum Digest, Vol.17,
Issue 79 23 February 1996.
[Neumann 1995] Peter Neumann, "Third Netscape weakness found", Risks-Forum
Digest, Vol.17, Issue 36, 27 September 1995.
[Neumann 1996] Peter Neumann, "More Java, JavaScript, and Netscape problems",
in "Security Risks in Computer-Communication Systems", ACM SIGSAC Review,
Vol.14, No.3 (July 1996), p.22.
[Plumb 1994] Colin Plumb, "Truly Random Numbers", Dr.Dobbs Journal, November
1994, p.113.
[RingZero 1995] `RingZero', "NEW Netscape RNG hole", posting to cypherpunks
mailing list, message-ID <[email protected]>, 8 October 1995.
[Robertson 1995] Richard Robertson, "Random Number Generators Draft", IEEE
P1363 Random Number Generators Review Group, May 1995.
[Sandberg 1995] Jared Sandberg, "Netscape's Internet Software Contains Flaw
That Jeopardizes Security of Data", The Wall Street Journal, 19 September 1995.
[Spafford 1988] Gene Spafford, "The Internet Worm: Crisis and Aftermath",
Communications of the ACM, Vol.32, No.6 (June 1989), p.678.
[Uhlig 1995] Robert Uhlig, "Security threat to Internet shopping", Daily
Telegraph, Daily Telegraph (paper edition), 3 October 1995, p.12.
[unssl 1995] ftp://ftp.csua.berkeley.edu/pub/cypherpunks/cryptanalysis/unssl.c.
[Walsh 1996] Mike Walsh, "Microsoft's warning", Risks-Forum Digest, Vol.18,
Issue 38, 26 August 1996
[Williams 1996] Eric Williams, "New Netscape 2.0/2.01 Security Issue (Java
Sockets)", posting to comp.lang.java newsgroup, message-ID
<[email protected]>, 1 April 1996.
[WSJ 1996] The Wall Street Journal, "Princeton Team Finds Bug In Part Of
Netscape Program", 20 May 1996.