Slashdot Mirror

Of course, us paranoid furriners used to legally run Fortify on the binaries to re-enable the 128 bit ciphers.

"Central clearinghouse" PKI is what SSL uses. SSL certificates are signed by Certificate Authorities (CAs), such as VeriSign. CAs are trusted entities who verify an applicant's identity before issuing them a certificate. A certificate is the same as a public key except that it has more information about the owner - usually the x.509 Distinguished Name which consists of a "common name" (CN), "organizational unit" (OU), "organization" (O), "locality" (L), "state" (S), "country" (C), and sometimes email. For instance, Microsoft's DN is CN=www.microsoft.com/OU=mscom/O=Microsoft/L=Redmon d/S=Washington/C=US. How do you know which CAs to trust? Web browsers typically have a built-in list. Anyone can act as a CA, but when someone views a website which is using one of that CA's certificates, the user's web browser should (and most do) display a warning. Go to Fortify's SSL test page and my HTTPS website. Fortify's certificate was issued by Thawte (who I believe is now owned by VeriSign), a widely-known CA whose certificate is in most/all browsers. My certificate is signed by the "Zevils CA", which doesn't really exist. Your browser should display a warning when accessing the zevils site but not when accessing the Fortify site.

The other popular method of PKI is known as the "web of trust." This is what PGP and GPG use. If you know someone in real life, you have proof of their identity (such as a driver's license), and you both have GPG/PGP keys, you should sign each other's public keys and upload the signed keys to the keyserver. Here's how the web of trust works (with help from the GNU Privacy Guard Handbook):

Alice knows Bob in real life. They both use GPG. Alice knows with absolute certainty that a certain key is Bob's key, and that Bob is who he says he is, so she signs Bob's key with her key. Alice and Bob discuss PKI every day at lunch and Alice knows that Bob has excellent judgement on when to sign a key, so she tells GPG that she trusts Bob's signature on a key as much as her own (she can also give Bob marginal trust or no trust - see GPG documentation for details.) Bob has signed Charlie's key. Thus, Alice trusts Charlie's key. The web of trust, at least in the GPG implementation, is quite flexible and does extend to a depth of more than one. See the GPG handbook for more information.

Of course, PKI is not a magical security fairy that sprinkles security dust on your keys while you're asleep at night. Bruce Schneier and Carl Ellison have written an excellent paper, Ten Risks of PKI (Computer Security Journal, v 16, n 1, 2000, pp. 1-7)

Perhaps it's not so funny as it's supposed to be...

It is not. Binpatching non-free software is not very funny, indeed. You could ask the fortify maintainers (-:

But back to topic: how can it be Debian's fault if non-free (thus, not really patchable) software has bugs?

(thinks)

Just following the Karma recipe, or was that supposed to be humorous? (-:

--
this post was brought to you by Andreas Fuchs.

Patches, rather than complete re-issue of code, might be a good idea. Back in the days when I was a mainframe system programmer one of the most common methods for the supplier (ICL) to provide bug fixes was by issuing patches. These were applied against the executable file, and were typically only 20 or 30 lines in length.

This technique does not seem to have become very popular with smaller systems. The only current example I can of is fortify.net who provide patches for 128bit security for Netscape (not needed so much now that Netscape are allowed to export the 128bit versions.)

--

Just tested it at fortify.net

www.openssl.org has an Open Source implementation of SSL. I think their latest version is 0.95.

Are you suggesting that there is no difference?

Are you saying that netscape doesn't realize that people are not using redhat 4.2?

Please, there are many issues going into a moving a platform of a huge app, then just recompile.

Forget all that, let's put it like this: would you rather them fix 4.x or fix mozilla?

go to fortify to secure your browser, and for a kick, plug into: tool!

Another example is Fortify. This puts full strenght encryption back into Netscape browsers. I realise there are other reasons such as being able to share code etc but for the main part the real benefactors are only US vendors. Im fine down here in Australia with the products that are already available to me and Im sure many others around the world are.

"Patience is a virtue, afforded those with nothing better to do." - I don't remember

just if you're interested, the link is
www.fortify.net

OK so this is a hoax but it is indeed possible to get 128 bit encryption on Netscape just by using an Australian product: Fortify As it's not made in the US it doesn't violate any US export laws.
--

Immediate? Not really! I still get:

Bad Domain DNS NAME:
Host Name: adsl-145-99-x-x.snelnet.nl
IP Address: 145.99.x.x
Your DNS name probably won't be accepted.

Still have to go to Zedz and Fortify...

or without https http://www.fortify.net/README_ma in.html#comparison

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

or without https http://www.fortify.net/README_ma in.html#comparison

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

> ...www.fortify.com...

You mean: www.fortify.net

--j

Is this really a viable solution? I disagree with the moderator's opinion that the parent posting is "insightful".

Is someone going to create a trusted root CA that distributes server certificates free for the asking and that the major browsers are going to recognize as a valid signer by default? Or maybe Verisign will change their business strategy and just give away certs for asking nicely =)

And what about accessibility? Not everyone has an SSL-enabled web browser, let alone a 128 bit browser (I mean, it seems silly to get everyone to use http over SSL if we're not going to push for everyone to use 128 bit, eh?). My mom can use a web browser without much difficulty, but she probably isn't going to visit fortify.net to upgrade her browser to 128 bit. People who use speech readers with text-only browsers like Lynx may not be so keen to have to compile in SSL support themselves to be able to access the web. I don't think I have SSL support on my Palm either. Does WebTV have SSL support? blah blah blah etc etc etc....

There's the whole SSL performance issue too I suppose for those of us still trying to make cheap web servers out of leftover 486s (although if you were really hot and bothered by performance perhaps you wouldn't be using a 486 =)).

And this particular discussion is wasting its energies by focusing on what we as information providers or end-users can do to make up for government efforts to build tap-ability into our networks.

You might want to check out Fortify if you can't wait. I haven't used it myself, but I know several people who have. It turns a normal version of Netscape into the 128 bit version.

They just say either Internet Explorer or Netscape is required. Thanks....

What I tell people to do is to use Fortify (http://www.fortify.net) which updates your browser to 128bit (apparently)

This site upgrades netscape to 128 bit encryption and it is located outside the US. No control & no backdoor. Best of all, the source is available.

Now, only if Netscape put out a new 128-bit version of their browser...I'm using the 4.08 Navigator standalone and I swear it's buggy as hell.

I'm also in Europe, but i have strong crypto! When using netscape i rely on Fortify. This is a fully automated patch, just type install (or whatever) a few stupid questions, and voila... then you can repackage it and even distribute... When using IE, then there are strong versions on replay.com (Even a 128 bit WinCE IE is downloadable here).

Most encrypted communication on the net, and virtually all that's automatically negotiated (e.g. the SSL encryption spec your browser uses) consists of both a private and a public key section. RSA is the usual choice for the public key. That key is 512 bits long in your average export-crippled browser. The RSA key -- which is strong and has the public-key exchangeability benefit, is also computationally extremely slow -- RSA is slow, that's just how it is. So rather than encrypting the whole communication with RSA, RSA is used to encrypt another key, that being the secret key for the faster block cipher, typically IDEA, RC5, 3DES or (gods forbid) single-DES. The block ciphers generally use smaller keys because the computation involved in breaking a 128 bit IDEA or DES key is in the general neighborhood of breaking a 1024 bit RSA key; different algorithms, different relative strengths.

So, to summarize, your 56-bit browser crypto is referring to the private-key portion (rc5-56 and des-56). Your RSA is probably using 512-bit public keys; your browser should be able to tell you when you make an SSL connect f you want to check. So don't feel _quite_ so bad, but still, ditch the crippled browser. 56-bit secret-key crypto is too weak for any serious use, and 512-bit RSA, as Mr. S demonstrated, is now likewise.

I expect it's been posted elsewhere, but Navigator/Communicator 4.0x and earlier could be patched easily with a copy of sed(1). 4.5 and later probably could but I haven't worked out how; use Forify for them; it's effective and easy to use.

I'd argue that the goverment has accomplished something, they've prevented millions of "normal" US users from using strong encryption. Most Americans aren't going to jump through the ridiculous hoops to get the 128-bit versions of Netscape or IE, and don't know about things like Fortify. I believe this is the real goal of the export controls, and if so it has succeeded very well. If strong encryption were allowed to become ubiquitous it would be transparently built into email software (yes, you can do it now, but it takes work), supported at the OS level, and virtually all communication would be encrypted. And then our favorite three letter agencies couldn't use their wiretapping systems to spy on innocent Americans...um, I mean, to protect the children.

You talk of "spoofing" Microsoft or Netscape. Why not just use Fortify which is distributed from Australia - and so is NOT subject to standard US Export laws on Encryption - and which will increase the Export Grade Navigator/Communicator from Netscape to 128Bit. It's completely legal and best of all, it only works with Netscape NOT M$ :-)

Uh? You are describing SSL/TLS. Go get mod_ssl for Apache and Fortify to enable 128-bit ciphers in all Netscape browsers.

You can upgrade the international versions of Netscape to high grade encryption using Fortify, which is developed outside the US. No need to be stuck with 40 bits.

Second: all these inconveniences to get a secure browser to hide your communications are mostly useless considering the fact that only sites of very commercial nature let you use https (secure http via SSL/TLS). Of course, the point is not that "they" can see what we are talking about something on slashdot. They can see what we are talking about anything on anywhere.

U.S. is still pretty much driving the internet communications, protocols, applications and implementations, and when at every point we are limited to non-encrypted traffic, the bad guys still can get the whole picture (see, the bad guys even have the habit of defining the bad guys..). It's important do anything to get the U.S. lift those crypto controls, the regulations are not there for you! We would be in a much safer world where encryption would be ubiquitious, including even protocols like DNS, SMTP, POP3, HTTP. Maybe they would be a bit slower, but there would finally be another reason to get faster CPU's other than to run Bloatware version N+1 from MS. :)

I don't know if it will work with this new 4.6 version, but I'm going to try it. I'm sure they'll add official support for it soon enough.
----------

Use Fortify. Netscape doesn't seem to have any glibc versions of its 128 browsers out anyway, so those with glibc systems are stuck with either 40 bits or Fortify if they want a relatively stable browser.


Then again, don't take my word, I haven't downloaded a copy since 4.51 came out.


AC

For the symmetric systems, brute force checking of the whole keyspace is the only way to crack them. That means checking all of the 2^128 (lots!) possible keys. Asymmetric key systems are vulnerable to factoring attacks, as they make use of really big prime numbers to protect data.

For everyone not in the US (your export laws suck, people!) check out Fortify.Net to upgrade Netscape to 128-bit crypto.