Fortify for Netscape

Farrell McKay
14 Oct 1997

This is Fortify for Netscape, a program that provides world-wide, unconditional, full strength 128-bit cryptography to users of Netscape Navigator (v3) and Communicator (v4).

What versions of Netscape does it support?
I'm impatient. How do I run it?
What else do I need to do?
What exactly does Fortify do?
What does it not do?
But doesn't Communicator already have 128-bit encryption?
Where can I get the most recent version?
How do I check the encryption strength of my copy of Netscape?
What's all this about RSA/RC4/40-bits/512-bits/symmetric keys? I'm confused.
How strong is a 40 bit secret key anyway?
Has anyone ever "broken" one of these keys?
Why should I bother with Fortify? Who cares!
Is there some way I can help this project?
Where do I send feedback or questions?
Further bed-time reading

What versions of Netscape does it support?

The current release of Fortify supports all of the following non-beta Netscape browsers (English edition):-

Navigator Standard verns 3.01, 3.02, 3.03
Navigator Gold verns 3.01, 3.02, 3.03
Navigator Lite (stand-alone) verns 4.02, 4.03
Communicator verns 4.01, 4.01a, 4.02, 4.03
that were released for the following platforms:-
Alpha DEC-OSF (*)
Mips SGI-Irix 5.x and 6.x
Sparc Sun-Solaris 2.x
Sparc Sun-SunOS 4.1.3_U1
x86 Linux-Elf
x86 Microsoft Win95 and WinNT

(*) The 4.03b8 beta releases for DEC-OSF are also supported.

Is your platform or operating system missing from this list? Can you provide ssh or telnet access to your machine? If so, please get in touch! Your resources are valuable to this project. All offers gladly received.

I'm impatient. How do I run it?

Before running Fortify, you will need to know the full path name of your Netscape executable program on your hard disk.

Then, if you are using Windows-95 or Windows-NT, do this:-

  1. Make sure you are not running Netscape at the moment.
  2. Unzip the distribution on to your local hard disk.
  3. Run the Fortify.exe program that is in the top level directory, e.g. by typing the command
    Fortify.exe C:\Program Files\Netscape\Program\netscape.exe
  4. The program will prompt you for any additional information or confirmations as it proceeds.
  5. Hit the surf.

Or, if you are using Unix, do this:-

  1. Make sure you are not running Netscape at the moment.
  2. gzip -dc Fortify-1.1.0.tar.gz | tar -xf -
  3. cd Fortify-1.1.0
  4. ./ [your-Netscape-filename ...]
    e.g. ./ /usr/local/bin/netscape
  5. The script will prompt you for any additional information or confirmations as it proceeds.
  6. Hit the surf.

Following these steps will cause a precompiled copy of Fortify to be executed during the upgrade. If you are not happy with the thought of running a precompiled program that you have downloaded from the net, then feel free to rebuild it for yourself. The source code can be found in the 'src' directory. You will need an ANSI-C compiler such as 'gcc'. Simply edit the src/Makefile file to select your platform, and then type 'make'. The src/README file contains a few additional lab notes.

What else do I need to do?

You should flush your Netscape memory and disk caches.

This is not strictly necessary, but it will avoid confusion if you are in the habit of checking the "Document Information" screen. This screen reports the SSL secret key length that was used when the document was fetched from its home web server - which might be earlier than the time when Fortify was applied if it is a cached document.

You should also check your SSL cipher preferences. If you normally use a non-default set of SSL ciphers, you may wish to review your choices. After running Fortify you will have an improved set of ciphers to choose from. The SSL cipher controls are in the Security Preferences dialog of the Options menu (v3), or the Security Info window of the Communicator menu (v4).

What exactly does Fortify do?

Netscape has possessed the ability to perform SSL encryption ever since the version 2.0 release. The cipher functions have no inherent key length limitations. However, the export grade browser only generates and uses 40-bit secret keys (padded out with clear text key material where needed).

Fortify simply arranges for Netscape to generate and/or use 128-bit secret keys whenever possible. It achieves this by installing itself directly in to the Navigator browser at a small number of specific places. Thus, no SSL proxy servers or relays are involved. No supplementary libraries or support programs are installed. No helper applications are needed. No special certificates are required in either the server or the browser.

You start with a vanilla copy of Netscape. You run Fortify against it. You finish with a Netscape executable that is equally as strong as the U.S. domestic version. You then use it in the normal manner. The next time you connect to any full strength SSL server, 128-bit encryption will be used, end-to-end, from the server right through to your browser. No other re-configurations or adjustments are necessary.

Before upgrading your copy of Netscape, Fortify will perform a number of preliminary checks. It checks that a) it has write permission on your Netscape program, b) that it can recognize your Netscape program as a known version (its file size and MD5 fingerprint are used for this), and c) that the installation for that Netscape version can be applied without error. If all three tests pass, Fortify then proceeds with the upgrade.

Passing a '-n' parameter to the Fortify script will cause it to run in 'nowrite' mode. Normal processing occurs, but nothing is actually installed.

For your added peace of mind, Fortify will offer to retain a backup copy of your browser in the same directory.

At any time you may remove the upgrade from your Netscape browser. You do this simply by re-running Fortify against your copy of Netscape. Fortify will detect the upgraded nature of your browser and offer to reverse the upgrade. Reversing the upgrade returns your browser exactly to its original form.

What does it not do?

Foritfy does NOT

  • introduce any new functionality into Netscape.
  • plant any trojan horses, viruses, time bombs etc.
  • affect any of Netscape's non-SSL code.
  • affect any of Netscape's low level cryptographic algorithms such as RSA, RC2, RC4, DES, MD5, SHA etc.
  • affect Navigator's RSA key length limitations (*)
  • cook your breakfast.

    (*) Standard export-grade Navigator can accept and process RSA keys of 1024 bits from an SSL server. The much-publicised 512 bit key length limitation only applies to internally generated RSA keys, which are generally only used for client authentication - they have no direct bearing on an SSL connection's cryptographic strength.

    But doesn't Communicator already have 128-bit encryption?

    The latest export release of Netscape Communicator (version 4) includes two high grade ciphers - RC4 128-bit, and triple-DES 168-bit.

    However, you must read the fine print. These ciphers are only enabled when you connect to specific, specially approved SSL servers (if you connect to a non-approved SSL server, the strongest cipher allowed is 56-bit DES). Verisign Inc. grants these special approvals. Outside the U.S. approvals are only available to certified banks. To date, there have been no announcements of any such approvals having been granted.

    In contrast, Fortify gives you strongly encrypted communications when you connect to any full strength server, anywhere. No questions asked. Fortify is available for both Navigator (v3) and Communicator (v4).

    Where can I download the most recent version?

    The Fortify home page is on the net, currently at Please refer to that site for download details, and all the latest news about Fortify.

    How do I check the encryption strength of my copy of Netscape?

    You have a few alternatives.

    1. The simplest method is to restart Netscape, or call up the "About..." page from the Help menu. On this page you will see a section describing the program's cryptographic features.

      The Unix export versions of Netscape describe themselves as
      "This version supports International security ........."

      Fortified versions (and presumably U.S. domestic versions) describe themselves as
      "This version supports U.S. security ..........."

    2. The most direct evidence of your browser's cryptographic capabilities is in the SSL cipher preferences dialog box, in the security manager.

      Export versions of Navigator (v3) offer 40-bit RC2 and RC4 ciphers (example), whereas the Fortified version offers 128-bit RC4 (example).

      Export versions of Communicator (v4) offer 40-bit RC4 normally, or 128-bit RC4 and 168-bit triple-DES when a "blessed" server is involved (example). Fortified versions, however, offer 128-bit RC4 and 168-bit triple-DES without restriction (example).

    3. Alternatively, you can connect to any public full strength web server, for example, and download a page. You can see the encryption strength of the connection in two places:-

      a) In Navigator v3, the small key icon in the bottom left hand corner of the browser indicates the encryption status.

      A broken key symbol indicates no encryption
      A solid key with a single tooth signifies an export grade cipher (40-bits)
      A solid key with two teeth signifies a full strength cipher is in operation.

      b) The "Document Information" screen reports the cipher and key length that was used when the document was fetched. Strong ciphers are described as "a high-grade encryption key ....", while weak ciphers are described as "a medium-grade encryption key ....".

    4. If you are the skeptical type, find yourself a trustworthy web server that tells you about the strength of each incoming SSL connection. There are a few of these on the net. It would defeat the goal of independent verification to list URLs here, but if you are stuck, you should try searching through the Netcraft SSL Servers Survey at

      Alternatively, find an Apache-SSL web server that has the "printenv" cgi-bin script installed ("printenv" prints all the environment variables passed to itself; it is included in the vanilla Apache distribution). Open an SSL connection to this script, e.g.

      Export versions of Netscape will see a HTML page returned by printenv that includes these lines:-

              HTTP_USER_AGENT = Mozilla/3.01 (X11; I; ...platform...)
              HTTPS = on
              HTTPS_CIPHER = EXP-RC4-MD5
              HTTPS_KEYSIZE = 128
              HTTPS_SECRETKEYSIZE = 40

      Fortified versions (and presumably U.S. domestic versions) will see a HTML page returned that includes these lines:-

              HTTP_USER_AGENT = Mozilla/3.01 (X11; U; ...platform...)
              HTTPS = on
              HTTPS_CIPHER = RC4-MD5
              HTTPS_KEYSIZE = 128
              HTTPS_SECRETKEYSIZE = 128

    5. If you are the mis-trusting type, find yourself (or build) a trustworthy web server that only accepts U.S. domestic strength SSL connections. Export version of Netscape will fail to connect to such a server, but Fortify'd Netscape will succeed.

      You can also perform the reverse test, i.e. using only high grade ciphers connect to a server that only accepts export strength SSL connections. Amazingly, the server at Verisign ( is an example in this category!!

    6. If you are the deeply suspicious type, you are going to need some tools of your own. You can either

      a) build a test bed server that dumps out SSL conversations (ApacheSSL + SSLeay makes a fine starting point for this),

      b) snoop the https packets that pass between the browser and web server across a network link.

    What's all this about RSA/RC4/40-bits/512-bits/symmetric keys? I'm confused.

    To cut a long story short, there are two types of keys used by Netscape. One is a "secret key", which encrypts and decrypts your transmitted data. The secret key is generally between 40 and 168 bits in size, depending on the cipher involved.

    The second key type - the RSA key - actually manifests itself as two keys, a public and a private key pair. These are used when a new SSL connection is established to securely exchange secret keys. Public and private keys are generally at least 512 bits in size.

    All this is a gross simplification of SSL key theory. If you want to know more, you should refer to one of the many fine SSL reference documents available on the Web.

    How strong is a 40 bit secret key anyway?

    It is feeble.

    Netscape Communications peg the computation effort to exhaustively search a 40 bit key at approximately 64 MIPS-years (MIPS = millions of instructions per second). This means that it would take a 1 MIPS computer 64 years to find a 40 bit key value. A 64 MIPS computer would take one year to do the same task. Two such computers would need 6 months of computation. And so on.

    Digital Equipment Corporation announced in July 1996 a version of its 64-bit Alpha 21164 RISC chip that is capable of 2000 MIPS. Hook together, say, four CPUs of this power, and you have a machine that can exhaustively search a 40-bit key space in (64 * 365) / (2000 * 4) = 2.92 days. On average, a key search will reach its goal in half the maximum search time, i.e. 1.46 days. This is a crude example. The inescapable conclusion is that large corporations, governments, and intelligence agencies already have the ability to break 40-bit keys in real-time. The encryption is transparent - like using glass windows against a peeping tom.

    Similar deficiencies can be seen in the 56-bit DES algorithm. DES is roughly twenty years old. At the time it was designed and published it was regarded as being sufficiently strong, given the computing power that was available in the 1970s. Since then the algorithm has remained unchanged, and our technology has made quantum leaps several times over. You can draw your own conclusions...

    In a recent article "Mimimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", several of the world's leading cryptographers "strongly recommend a minimum key-length of 90 bits for symmetric cryptosystems (unquote)". [Ref: here ]. 90-bit keys would appear to be acceptably strong in 1997. 128-bit keys are therefore what the world should be using.

    Has anyone ever "broken" one of these keys?

    Yes. Several times. One of the first public attacks on a 40-bit key was carried out in August 1995, as part of Hal's Challenge. The challenge was ultimately solved independently by two parties. The first party to find the key was David Byers and Eric Young, using approx 50 PCs, 15 workstations and a MasPar MP-1 for the search. The second person to find the key was Damien Doliegez (France), who used approx 20 workstations and two supercomputers for 8 days to conduct the search.

    A group known as the Cypherpunks have banded together to co-operatively conduct exhaustive key searches in record times using run-of-the-mill computing resources. Their fastest time for a 40-bit key search currently stands at 31 hours 47 minutes, which was the time taken to break Hal's Second Challenge, also in Aug 1995.

    In January and February of 1997, two more cryptography challenges were broken. The first was a 40-bit cipher key that was broken in a mere 3.5 hours by Mr. Ian Goldberg at the University of California, Berkeley, using a network of approx 250 PCs and workstations. The second was a 48-bit cipher key that was broken in approx 13 days by a collaborative group of approx 5000 computers operating across the Internet.

    56-bit DES has also been "broken". In June 1997 the Deschall group, headed by Mr. Rocke Verser, announced the winning key to the RSA's DES challenge. Deschall was, once again, an Internet-based collaborative effort. The group used the spare CPU cycles from "tens of thousands" of standard computers, over a period of roughly four months, to perform the key search.

    These and other challenges were published by RSA Inc. on Jan 28th as part of a research exercise into the security of export grade ciphers. The exercise is on-going

    Why should I bother with Fortify? Who cares!

    Let's keep the politics to a minimum, ok? Suffice it to say that privacy is a right, and that the U.S. government's cryptographic export restrictions are helping no-one (with the possible exception of itself). If you use a web browser for anything that is even slightly personal, valuable or sensitive then you need strong encryption.

    Strong encryption exists right now. It is proven, it is practical, it is reliable and it is cheap. It is by far the best possible solution to a worldwide need. Anything less is a scam.

    Say "No" to key escrow.
    Say "No" to Clipper chips.
    Say "No" to key recovery systems.
    Say "No" to diluted key lengths.
    Say "No" to cryptography that comes with "strings attached".

    Is there some way I can help this project?

    Yes. Definitely. This project can potentially be extended into many related areas - other browsers, other servers, other protocols etc. However it is running on a tight budget and minimal resources. Any offers would be welcome, particularly if they involve:-

  • bandwidth - e.g. resources on a well-connected ftp/web server.
  • access - e.g. ssh or telnet account into any Unix system.
  • hardware - e.g. old, unloved machines that need a new home.

    Where do I send feedback or questions?

    If you have a moment, please take the time to fill in the feedback form. You can register your interest in future announcements about Fortify, or you can have a say in the project's future direction.

    If you wish to send an e-mail message, please address it to .

    Further bed-time reading

    The 'doc' sub-directory contains copies of several relevant articles and references, taken from the web. Read them at your leisure.

    You can also read much more about this at several sites on the net, for example and


    This toolkit contains a slightly modified copy of the 'md5' component of the SSLeay-0.6.3 distribution. SSLeay is written and distributed by Eric Young, Many thanks, Eric!