![]() |
Fortify for Netscape http://www.fortify.net/ 3 Oct 1998 |
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). |
In the Netscape 2.x and 3.x browsers, Fortify provides full strength, 128-bit encryption facilities. These are used when connecting to an encrypting web server (with the SSL protocol). Without Fortify, the export-grade web browsers are limited to 40-bit encryption facilities, which are substantially weaker, and have been demonstrated to be "crackable".
In the Netscape 4.x browsers, Fortify provides these same 128-bit encryption features, plus the ability to generate 1024-bit RSA keys internally (these are typically used for client certificates), plus the ability to send and receive e-mail messages using strong 128-bit encryption (with the S/MIME protocol).
Further details are provided in the following sections of this document.
When comparing Fortify to alternative strong encryption solutions, such as SSL relays, SSL proxies, or Java-based applet solutions, a number of advantages are worth considering:
The recent export releases of Netscape Communicator (version 4 only) include two high grade SSL 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 web servers (they are never used to encrypt e-mail messages). If you connect to a non-approved SSL server, the strongest cipher allowed is 56-bit DES. Verisign Inc. grants these special approvals, under its Global Server ID certificate program. Outside the U.S., approvals are only available to certain, specific categories of organizations.
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).
Microsoft Internet Explorer also possesses 128-bit cryptography, but it too is conditional. It is only enabled when connecting to specific, pre-approved web servers, under a scheme named "Server Gated Cryptography". In this respect, it is the same as Netscape Communicator. Do not be misled by statements that suggest anything else.
No version of Fortify for MS-IE is available at this time.
The current release of Fortify supports all of the following non-beta Netscape browsers (English edition):-
(*) BSD versions v3.01, v3.03-gold, v3.04, and v4.04 onwards only.
(+) OS/2 version v2.02 (service level 4, 7 or 8) and 4.04 only.
Is your platform or operating system missing from this list? Then now is your chance to cast a vote for your platform. Please take a few moments to fill in the Fortify feedback form. (details below), and indicate which operating system(s) you use.
Fortify for Netscape is not explicitly regression tested against any of the international editions of the Netscape browsers.
However, the international and English browsers all use the same underlying Netscape executable program. Fortify can be expected, therefore, to successfully recognise and upgrade these browsers. Indeed, many Fortify users have already reported this to be the case.
Specific beta or preview releases of the Netscape browsers may be supported from time to time, but, in general, there is no on-going guarantee that these editions are supported. Being preview releases they come in fairly low on the priority list, since they typically have short lifetimes, they are of a poorer quality, and they stretch resources disproportionately.
If you would like to see a particular preview release supported, feel free to say so, and keep an eye out for future announcements (or subscribe to the Fortify mailing list).
Yes.
Naturally, this guarantee does not extend to cover the entire functional definition of Netscape's browser. It only covers the functionality provided by Fortify for Netscape.
Yes. In fact, a fortified browser will always use 128-bit encryption when connecting to any strongly encrypting web server - regardless of the server certificate involved. For encryption purposes, the browser draws no distinction between the various server certificates.
The Fortify home page is on the net, currently at http://www.fortify.net/ Please refer to that site for download details, and all the latest news about Fortify.
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:-
pkunzip -d -e fn126w32.zip
cd fn126w32
Fortify.exe "C:\Program Files\Netscape\Program\netscape.exe"
fn126w32
folder if you wish. If you think you might wish to uninstall
Fortify some time later, you should retain a copy of the Fortify
distribution archive. This is your choice.
Or, if you are using OS/2, do this:-
pkunzip -d -e fn128os2.zip
cd fn128os2
Repack.exe /EXEPACK:0 C:\Netscape\netscape.exe
Fortify.exe C:\Netscape\netscape.exe
Repack.exe /EXEPACK:2 C:\Netscape\netscape.exe
del C:\Netscape\netscape.bak
C:\Netscape\netscape.exe
rather than
C:\Netscape\netscape.bak
(this is a side effect of using repack.exe)
fn128os2
folder if you wish. If you think you might wish to uninstall
Fortify some time later, you should retain a copy of the Fortify
distribution archive. This is your choice.
C:\Netscape\netscape.exe
is shown as an example only.
You should substitute the full path name of the Netscape executable
installed on your machine.
4.04-beta netscape.exe
files using
repack.exe
.
The problem arises from the netscape.exe
being locked by
a running process, and it appears to have been fixed in the latest 4.04 non-beta
release of Communicator.
Details about the problem scenario, and a suggested workaround can be found
here.
Or, if you are using Unix, do this:-
unix-TYPE
:
gzip -dc Fortify-1.2.6-unix-TYPE.tar.gz | tar -xf -
cd Fortify-1.2.6-unix-TYPE
./Fortify.sh [your-Netscape-filename ...]
Fortify-1.2.6-unix-TYPE
folder if you wish. If you think you might wish to uninstall
Fortify some time later, you should retain a copy of the Fortify
distribution archive. This is your choice.
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.
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).
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.
In the Netscape 4.x browsers, Fortify also upgrades security in two additional areas - the maximum RSA key size and the S/MIME e-mail ciphers. The maximum RSA generated key size is raised from 512 bits (export-grade) to 1024-bits (domestic-grade). Internally generated RSA keys are typically used for client certificates, i.e. for authentication purposes.
Strong encryption is provided for your e-mail messages with the presence of four strong S/MIME encryption ciphers that are not otherwise available in the export browsers. These ciphers are triple-DES 168-bit, RC2 128-bit, RC2 64-bit and DES 56-bit. With these ciphers in operation, your e-mail privacy is substantially enhanced.
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. The backup file is given a '.sav' file extension.
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.
Fortify does NOT
Nothing. Fortify will only recognise and upgrade export-grade browsers. Of course, if you have a U.S.-Domestic browser, you don't need Fortify. But there is no risk of accidentally damaging your browser through the use of Fortify.
You have a few alternatives.
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 ..........."
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 for web connections, or 128-bit RC4 and 168-bit triple-DES when a "blessed" web server is involved (example). Fortified versions, however, offer 128-bit RC4 and 168-bit triple-DES without restriction (example). For sending and receiving e-mail, Communicator (v4) offers 40-bit RC2 only (example), whereas Fortified versions carry an additional four strong e-mail ciphers (example).
a) In Navigator v3, the small key icon in the bottom left hand corner of the browser indicates the encryption status.
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 ....".
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. https://some.server.name/cgi-bin/printenv.
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
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 (www.verisign.com) is an example in this category!!
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.
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.
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 "Minimal 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.
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", on at least four separate occasions. The Deschall group, headed by Mr. Rocke Verser, announced the winning key to the RSA's first DES challenge in June 1997. 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.
The second DES challenge was completed in February 1998, by a collaborative group known as distributed.net in 39 days - one third of the time taken to solve the first DES challenge.
The Electronic Frontier Foundation has accomplished at least two separate 56-bit DES "cracks" in June and July, 1998. The most widely publicized result was a solution to the RSA DES II challenge. The solution was achieved in 56 hours - substantially faster than the previous record. These results once again demonstrate the fact that export grade ciphers, including DES, are largely ineffective, and their usefulness degrades rapidly over time.
These and other challenges were published by RSA Inc. on Jan 28th, 1997 as part of a research exercise into the security of export grade ciphers. The exercise is on-going
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 - and sooner or later you will - 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 sham.
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".
Fortify for Netscape was developed in Australia, using all Australian resources, with no assistance from Netscape Communications. As such, it is beyond the ambit of the U.S. Government's export controls.
Australian export regulations do not currently restrict export of cryptographic software by electronic means, such as FTP or e-mail.
You may have the misfortune of being subject to laws in your home country that restrict or prohibit the possession of strong cryptography. In such situations you may find that you cannot legally use Fortify for Netscape together with a Netscape browser.
Fortify for Netscape is not a Netscape product. Furthermore, the U.S. export laws prevent Netscape U.S. from providing any official endorsement or support for Fortify. You must weigh up this fact against the acceptability of export-grade cryptography. Support and assistance relating to Fortify for Netscape is available via the the feedback form on the Fortify web site.
Of course these are not legally authoritative statements. If necessary, you should obtain proper legal guidance from experts in your home country.
Yes. The Fortify mailing list is a low volume, read-only list for people who are interested in receiving bulletins and announcements regarding the Fortify project. It is not a discussion forum - mail messages sent to the list are not redistributed.
You can subscribe to the Fortify mailing list simply by clicking on the button below. Or you can use this more flexible interface to supply a different subscription email address, or to unsubscribe from the list. If you get stuck, you can send an email message to majordomo@fortify.net with the single word help in the body of the message. In reply, the list server will automatically send you the instructions for joining and leaving the mailing list.
If you have a moment, please take the time to send in your feedback via the Fortify web site. At the same time you can subscribe to the Fortify mailing list, cast your vote for a currently unsupported platform, or lodge a call for support assistance.
This toolkit contains a modified copy of the 'md5' component of the SSLeay-0.6.3 distribution. SSLeay is written and distributed by Eric Young, eay@cryptsoft.com. Many thanks, Eric!