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