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:-
- Make sure you are not running Netscape at the moment.
- Unzip the distribution on to your local hard disk.
- 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 - The program will prompt you for any additional information or confirmations as it proceeds.
- Hit the surf.
Or, if you are using Unix, do this:-
- Make sure you are not running Netscape at the moment.
-
gzip -dc Fortify-1.1.0.tar.gz | tar -xf - -
cd Fortify-1.1.0 -
./Fortify.sh [your-Netscape-filename ...]
e.g../Fortify.sh /usr/local/bin/netscape - The script will prompt you for any additional information or confirmations as it proceeds.
- 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.
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.
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.
Foritfy does NOT
(*) 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.
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).
The Fortify home page is on the net, currently at
http://www.geocities.com/Eureka/Plaza/6333/
Please refer to that site for download details, and all the latest
news about Fortify.
You have a few alternatives.
The Unix export versions of Netscape describe themselves as
Fortified versions
(and presumably U.S. domestic versions)
describe themselves as
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).
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:-
Fortified versions (and presumably U.S. domestic versions) will see a
HTML page returned that includes these lines:-
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 "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.
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
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.
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:-
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
Farrell.McKay@mpx.com.au
.
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
http://www.privacy.org/
http://www.eff.org/
and
http://www.crypto.com/
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 download the most recent version?
How do I check the encryption strength of my copy of Netscape?
"This version supports International security ........."
"This version supports U.S. security ..........."
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.
HTTP_USER_AGENT = Mozilla/3.01 (X11; I; ...platform...)
HTTPS = on
HTTPS_CIPHER = EXP-RC4-MD5
HTTPS_KEYSIZE = 128
HTTPS_SECRETKEYSIZE = 40
HTTP_USER_AGENT = Mozilla/3.01 (X11; U; ...platform...)
HTTPS = on
HTTPS_CIPHER = RC4-MD5
HTTPS_KEYSIZE = 128
HTTPS_SECRETKEYSIZE = 128
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!
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?
Where do I send feedback or questions?
Further bed-time reading
