[2593] in cryptography@c2.net mail archive
Re: safety of SSL 2?
daemon@ATHENA.MIT.EDU (Eric Young)
Tue Apr 28 14:43:27 1998
Date: Tue, 28 Apr 1998 15:47:42 +1000 (EST)
From: Eric Young <eay@cryptsoft.com>
To: Rick Smith <rick_smith@securecomputing.com>
cc: Rodney Thayer <rodney@sabletech.com>, cryptography@c2.net
In-Reply-To: <v03007801b16a4b6b205d@[172.17.1.150]>
On Mon, 27 Apr 1998, Rick Smith wrote:
> At 11:09 AM -0400 4/25/98, Rodney Thayer wrote:
> >I recently ran across a web site that used SSL 2 for security. Now I
> >wouldn't have noticed of course if I hadn't carefully disable that in
> >Netscape. How (in)secure is SSL 2, in reality? I realize 'we' (the loud
> >characters in the crypto implementor space) consider it rather unsafe, but
> >what does, or, should that translate to in The Real World?
>
> The Real World has a *huge* tolerance for lax security. Announcements of
> Netscape security problems occurred during a run-up of their stock price,
> and the stock price was barely affected.
www.amazon.com still only accept SSLv2 (and a broken implementation at that).
It is all a mater of risk managament. When the posible costs are very low,
they will not upgrade. The loss of revenue and the hassles to upgrade to the
latest and greatest microsoft/netscape/Apache point release every 2 weeks does
tend to make people not upgrade.
> There are several problems with SSL 2, but my "favorite" is the use of the
> same crypto key for both encryption and integrity protection. So if you're
> talking in "international" mode with 40 bit keys, you face an integrity
> risk as well as a disclosure risk, assuming the adversary has some really,
> really serious computing power available for real time cracking. This
> should still be safe enough for commercial credit card transactions, but
> it's probably not safe enough for significant, irreversible transactions
> ("launch nukes").
But this is still the case with SSLv3 and TLSv1. This is an issue of export
ciphers. Granted, there is the SSLv2 'rolback to export cipher' attack.
SSLv3 introduced seperate authentication/encryption keys, (ephemeral DH)
but just about no-one implements them (until recently it was only SSLeay and
most of the java implementation). There is more of a security hole because of
the lack of backward security if the server key is ever compromised. All
trafic in the past is disclosed. (I'm ignoring the ephemeral RSA which
only operates if you have an export cipher or signing only RSA keys).
> > Should Verisign
> >stop supporting sites that use it, for example?
>
> Verisign is running a *huge* annual loss and they can't afford to discard
I'm still wondering how they will ever make money :-).
> part of their customer base. People have invested lots of money in the
> notion that crypto can make things better. If they fail to make money
> because a particular product isn't perfect (hey, it never will be) then the
> basic technology will be blamed, and not the subtle features of the crypto.
> Look at what's happening with e-cash.
Concensus informs us that SSLv3 supports client authentication while SSLv2 did
not. This is wrong, and there are deployed systems that use SSLv2 client
authentication, but this dis-information is probably about the only way to
force people to move to the new protocols. Added functionality that the
busness can use will cause upgrades, not an extra level of warm and fuzzies
from the technical people.
> > Should there be cert advisories on it?
> The SSL3 spec has a nice summary of the bad things. I also summarized them
> in "Internet Cryptography." I doubt CERT will issue anything until someone
> produces a cracking script that bad guys can use successfully. As far as
> I've heard, existing cracking scripts have only been used as demos. I can
> imagine someone using a 40 bit cracking script to capture passwords to
> access "private" sites, but I haven't heard of anyone causing identifiable
> trouble this way.
I had a few hooks in old versions of SSLeay so that given the RSA private
key, the packet data, SSLeay could be run in reverse and output the decrypted
data. This would still apply to SSLv3/TLSv1 when they are using a single RSA
key for encryption and authentication (still mostly the case). Collect data
until you want to break in and get the private key (which is probably not
encrypted, or is encrypted with some 5 character phrase). Then simply decrypt
all the data from the last x months that you collected. Just about no-one
deployees the SSLv3 ciphers that would stop this kind of attack.
> Analog cel phones are far, far less secure than SSL2, but people aren't
> assumed to be negligent because they use them. The only exception would be
> if someone decides beforehand that cel phones aren't sufficiently secure
:-) The GSM digital phones are currently proving themselves not to be the
panacea for phone fraud. Phone companies do not care if people can listen in
on your calls, they only care about fraud by stealing you phone identity.
As has recently been made public, this is easy to do (<$100 of hardware).
SSLv2 breaking is much much harder and time consuming than cloning a digital
phone you borowed from work overnight.
eric
