Re: NetScape's dependence upon RSA down for the count!

[jbass@dmsd.com (John L. Bass)]

> The point to attacking SSL is to be able to decode a message from any
> browser, without having to do anything extraordinary to the victim's host.
> No cryptosystem is proof against an attacker who can see and
> control everything you do on the client side (i.e. has root in UNIX
> parlance).
> 
> So, while your idea #1 might be interesting or fun to do as far as computer
> security goes, it's not an attack on SSL. 

Agreed, within limits. Security as "Marketed" by NetScape goes far past
just claiming SSL to be secure, including the use of NetScape client
and servers as secure. With this expanded model, attacking NetScapes
claim of security includes attacking the process and enviornment that
they provide to endusers and info mall businesses. In this case
electronicaly distributing clients in a hostile environment is a gross
disregard for endusers security needs, traded off for ease of distribution.

I probably should not have included virus attacks, and just focused
upon the main problem ... unsecured network transmission of clients.

As it stands, a third party with minimal trouble can compromise a very
large number of NetScape clients and capture the dredit card data for
those users who would otherwise expect their transactions to be secure.

To take the ground that their product is secure in a secure environment
is meaningless ... the product value they seem to offer is security in
a non-secure environment - which I don't think is true, and I gather
you might agree?

> That points out the flaw in Netscape's authentication model that
> others have already pointed out on this list.  Admittedly, like Don
> Stephenson just posted, there's not really a good way to distribute
> and authenticate certificates until there's a ubiquitous global
> CA chain.

Again, we agree that this reflect negatively on NetScapes claims of
security in an unsecure environment?
	
As an aside, readers in private have suggested that a signature by
Verilog as the CA my not be required, quoting that until receintly,
NetScape signed their own certificates. This seems that the MITM
can choose his own CA, possibly of his own design to sign false
certificates.
	
> Assume that the attacker Mallet is in the middle and has control of the http
> stream.  Alice clicks on 'open Widget order form' to order a Widget
> and Mallet sends her browser a redirect pointing to his evil web server.
> Alice doesn't notice that the hostname in the url has changed, or
> if she does, she figures that the catalog people have arranged to
> have Mallet's server host their 'secure' transactions (not an unreasonable
> assumption).  Mallet takes the order and pockets the money.
> The hostname in the certificate (Mallet's) matches the hostname
> in the URL (also Mallet's).

Or Mallet places the order in Alice's name defering the chances of detection
until enough cards numbers are aquired to make a run on the bank. There is
tremendous value in forstalling the point of detection and the location of
the MITM becoming known. If Alice get's her goods promptly she is much less
likely to question the transaction.

> Of course this isn't really an attack on SSL per se.  It's an attack on
> the certificate-granting policy- the CA gave a certificate to
> an unscrupulous person (Mallet).

But it is a clear attack on NetScape's advertised "security" for end users.

Almost all sucessfull crooks/thieves have a front business to launder their
money thru. In this case you can steal customers just by redirecting your
competitor's DNS records to your server ... With a similar home page
and ordering/catalog screens they might never notice the switch, certainly
not first time customers. Gee nobody would probably own up to the occasional
named failures that could also cause this.

Somehow I don't think this is what endusers of info mall owners consider
security.

> > > Well of course, if the secret key of the server (or worse yet, certificate 
> > > authority) is compromised, all bets are off.  That's true of just about any 
> > > protocol you can dream up.
> > 
> > I'm not referring to the secret key of _the_ server; I'm referring to the 
> > secret key of _ANY_ server. In the limiting case, such a key can be 
> > obtained by buying one from the CA. 
> 
> Right. That's what I pointed out in an earlier message, although I
> didn't elaborate on it.   The security of Netscape browsers depends
> on Verisign's policy in handing out server certificates.

and on the physical security of the site plus it's network connections,
the trustworthyness of it's internal staff and contractors, and it's ability
to deliver service in the face of failures and disasters, both man made
and natural.

Security includes more than just crypto correctness, in this case it
include denial of service attacks as well has physical site attacks.

In this case I strongly suspect that bombing Verilog would shutdown
net commerce for a while. Certainly it's employees are in a position
to earn high six figures for the key algorithm or a copy of the key
database.

As for the policy, it has to include mom & pops and young business owners
setting out to make their honest fortune on the net ... unfortunately
this profile includes the evil side as well. I don't think restricting
info mall business to the fortune 500 is that we have in mind here.
As such, I don't think screening by the CA takes us very far at all.

> Backing up for a minute, the same problem holds for those neeto
> credit-card readers that Visa and MasterCharge give out to merchants.
> The merchant can be a crook setting up a 'store-front' operation to charge
> to bogus/stolen card numbers, or the employees can steal using the numbers
> they get in the corse of doing business, etc.  There are already
> procedures in place for dealing with this sort of crime.  I'm not
> sure that tricking Verisign into giving out a certificate to a group
> of crackers is really any different than tricking Visa into giving
> a card reader to a group of theives.

Volume greatly affect the risk factor. Giving a merchant number to a
business means that only the number of people that can walk-in or
phone in to that merchants store are at risk. Stolen cards are handled
differently than stolen numbers. Stolen numbers are cross correlated
by past purchase locations by store, and if possible by register location
and employee. There is a strong pointer to the person(s) involved.

Skimming card numbers off the net has the potential to cross vendors,
geographic areas, and other determinates that would aid in locating the
source of the tap. The number of card numbers exposed has the potential
to be several orders of magnitude higher, and remain undetected for quite
some time. The net offers the ability to place a large number of orders
in a short period of time for very high valued merchandice for delivery
to what would appear proper customers ... and using the UPS/FedX example
picking off the proceeds in a centralized low security location. With
another computer store front on the net, you turn the same hijacked goods
into full value shipments in a few days ... and maybe coordinate the
bogus orders and hijackings to meet your customers demands.

Or for an economic terrorist create $100 million in bogus orders and
deliveries to drive the system into failure.

Gone are the days when sheer man-power limited your exposure.  Gone
are the days when a sturdy building, good doors and locks, and a
security system backed by Well Fargo staff would protect your business.

Security in our network context includes not only the protection of
the individual consumer, but the info mall vendors and the future of
the medium as a viable way to do business. NetScape I believe is working
toward all three of these goals, I strongly disagree with the short
cuts and risks they are taking to get there.

John Bass