That would indeed be the "least" of your problems, albeit still a major undertaking in my opinion.

The big issue in my opinion, is to get the "standard" browser manufacturers to include the certficates signed by the "non-profit consortium" in the list of certificate authorities whose certificates are accepted by default. Without that, the browser will still display the rather unsettling message to the user. As you said yourself: "This damages your site's credibility and will result in a drastic loss of confidence on the part of your potential customers.". So any effort you try in that respect, would need to the full cooperation of Microsoft, it being responsible for +95% of the browsers used in the world (something I'm not happy with, but which is a reality nonetheless). You ponder the likelihood of Microsoft cooperating with such a venture.

I think you need to ask yourself why you would need a certificate. If it's for a webshop, then there are plenty of solutions available where the actual payment is handled by a payment handler where you can piggyback on the certificate of the payment handler. If you're interested in preventing eavesdropping for a particular application, I think you can explain to the users why they will be getting the unsettling message and just sign the certificate yourself.

Wish I could give some more positive comments. But with the current financial interest of the Internet, I don't see a non-profit consortium happening anymore. I think it would be simply too little, too late.

Liz

You ponder the likelihood of Microsoft cooperating with such a venture.

Here's the nice thing about Microsoft - they're a corporation. They do what will make them more money. They are not in the certificate-signing business. They are in the operating system, office, server software, and development environment business. It is in their interest to commodify everything that doesn't currently (or potentially) generate them more money. I can see a few problems, but nothing that can't be avoided if implemented in the proper order.

Of course IE is an exceptionally inferior browser lacking in core features (tabbed browsing for one) and all reports indicate its internals are a complete mess so it won't be the number 1 browser for too much longer. Also consider that Microsoft won't be the #1 OS company 5 years from now. So if there are problems, I see no reason to wait on them.

Most people want SSL to provide over the wire encryption for some of their data. The desired use of SSL is mainly restricted to protecting the logon form in a cookie based session management / authentication scheme. For this purpose, a certificate costing $1000 per year is over-kill and places the technology out of the reach of hobbyists and small-scale implementors.

If I am running an e-business site, my users might be interested to know that their credit card details are being sent to a company that has submitted it's legal status to the scrutiny of a CA. For somebody carrying out online monetary transactions, $1000 is probably a good investment.

The irony of the situation is that a web site that uses an SSL certificate based on a trusted CA is unlikely to provoke the user to review the validity of the certificate or site because it takes effort to review the security profile of the site. A site that uses a non-trusted certificate however, is immediately brought to the user's attention due to the prompt that appears.

It could be argued that a site that makes it quite clear that the user is being redirected to a page that will require them to accept a non-trusted certificate is no more harmful to the user experience than the sites that make you agree to pages of legal text before continuing. The user has the option of installing the certificate for future use. While not ideal, this approach gives over the wire encryption and raises awareness in end users.

inman

While we're bothering to educate users, why not explode the "Must Have Encryption on Credit Card Numbers" myth?

For a random person on the Internet, sniffing traffic to get credit card numbers (even if everything was sent in cleartext) is difficult, and doesn't get a very large reward. You'll have to get a machine physically on the network of a router, grab all the traffic (which could be well into gigabytes per day, or even per hour), and anylize all of it for CC nums.

Consider that many companies store the credit card on a machine sitting just outside their main firewall. There could be thousands of CC nums sitting on one of these machines at any one time. Compared to traffic sniffing, cracking into those boxes is often piss-easy (just wait for the next OpenSSH or Windows bug to come along--shouldn't take too long in either case). Those boxes are your main point of security failure, not SSL.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

The point about using SSL is that the traffic between your browser and the website is encrypted to minimise the risk of the content being intercepted on route. SSL does not solve any issues relating to storage or handling of the data at either end of the connection.

I am using a corporate network and access the internet via a web proxy. This is a situation that is not unlike being in a internet cafe or using a public wi-fi hotspot. There are people sat all around me using computers to do their work, book flights, buy concert tickets and pay their bills. I therefore could expect to have to 50+ users worth of traffic without leaving my desk. In a non-SSL world, I would probably only need to gather logon traffic for one day to get the passwords etc. and use the information for illicit purposes.

Security starts at home!

inman

I'm always amazed by how many people think that it really is necessary to store credit card numbers on a system exposed to the net in the first place. Storing unencrypted cc numbers in a database without being *very* careful is just plain dumb.

First, why does no one ever figure out if they ever need to know someone's credit card number again? A while back I wrote a transaction processing program for a non-profit -- the system only ever handles the full credit card number in memory during the course of the transaction authorisation. The log and database only ever store a checksum of the credit card. So it's not hard to demonstrate that the card number was used, but anyone else breaking into the system would end up with a lot of useless checksums (assuming that we've done our checksumming correctly).

It seems to me that you could envision a similar system working even where you *do* need to know the number on a repeated basis...

Two databases are established. One allows read/write/update access to scripts running on the web servier. The other only permits insert/write-only access to the same set of scripts.

The first time a customer places an order data is written to both systems. However, the db with read/update capability only stores a checksum of the card used. The second system stores the actual number (not ideal, but you could combine this with a public/private key infrastructure as well if you were really paranoid).

Future transactions would verify that the checksum was valid in the local database before transmitting the order to the second system for actual processing (which would need the real cc number).

You'd end up with a fairly robust system that could withstand several types of compromise fairly well... I think. Anyone want to poke holes in this?

If you want to steal credit card numbers get a job as a waiter. :)

For example, I once worked with a credit card processing system that used SSL to protect the transactions. That is a good thing because SSL is a very well designed protocol. The problem is that the server's certificate was signed by VeriSign. The client's used a CA file that listed the VeriSign CA. The problem with this is that any CA in the VeriSign tree could impersonate the server. This may be an acceptable risk for the shopping site, but it a big danger with the credit card processor that sits behind it.

What they should have done is signed the server certificate with by a custom CA. That CA would be the only one configured for clients. Clients should also get client certificates signed by the only CA that the servers trust. The trust is limited to the organization that runs the servers and issues the certificates.

Simarly, organizations shouldn't use the public CA tree for internal authentication like with email. It requires more work to distribute the CA certificate to all the clients but it is more secure because the trust doesn't include all the public CAs. On the other hand, since browser don't separate trust domains for certificates, the private CA could be used to spoof any web sites.

You can use Open SSL to generate a working valid certificate. The problem is simple. 95% of the browser market is IE. If a certificate signer is not on the list of 'valid' providers in IE then you get the pop up. M$ no doubt extorts money from those providers that get on the IE list. After all they can remove you from this list with the latest 'security' hotfix.....

The only practical solution is for a creative virus writer to write a virus that inserts 'OpenSSL INC' as a trusted certificate provider.....and hack OpenSSL to issue certificates from afore mentioned INC.

With M$ total domination of the browser market there is plenty of potential for all sorts of rorts.

Is what your $1000/yr buys you from VeriSign. That is to say that if they screw up(and it can be demonstrably assigned to them), allowing credit card info to be hacked, your idenity to be 'spoofed' by someone else, etc, that they have resources to PAY.

Let's not forget that the core statement of most Open Source licenses says: NO WARRANTY. In other words, if something goes wrong, you suffer damage to your systems, your reputation, your business you're out of luck.

Hopefully, some of the 1K also goes to things like R&D, testing on systems, infrastructure maintenance, and internal and external security. Things like background checks on the employees who actually handle the secured servers; bonded security guards on their data centers; good locks on the doors; good salaries to attract talented, if mercenary, people.

A 'non-profit' or 'open-source' sounds nice, but you're dependent on the 'good will' of the people maintaining and contributing to the system. What happens when a 'fund-raiser' falls short one year? Cheaper locks, no background checks on the guards, cheaper or fewer CPU's, thinner pipes?

Eventually a non-profit is going to have to charge fees anyway to maintain a secure system, or to validate people perhaps contributing their systems.

Profit my be an evil motive to some, but it is at its core an incentive to do things right. The Soviet Union spent 70 years learning that the hard way. Profit also supplies a pool of 'cash' to get things done without having the worry about a fundraiser. A track record of profits can also get banks to loan you money to upgrade your infrastructure.