Bill Stewart wrote:
At 11:38 AM 06/03/2003 -0400, Ian Grigg wrote:
I (arbitratrily) define the marketplace for SSL as browsing. ... There, we can show statistics that indicate that SSL has penetrated to something slightly less than 1% of servers.
For transmitting credit card numbers on web forms, I'd be surprised if there were 1% of the servers that *don't* use SSL/TLS.
I've seen it a lot. Not that I pay much attention, but I'd suspect it is less than 10%, but much more than 1%. Also, a lot of credit card numbers get delivered by email. These are all to small time merchants who have MOTO agreements without the net part, but take the CCs anyway. After all, a sale is a sale, and nobody ever heard of a credit card number being lost over the net... OK, I'm teased by this: how many sites use open unencrypted CC delivery? I went to google and searched on: "<form" credit card number expiry I found 2 on the first page, and 1 on the second page. There were 240,000 hits. So, we are looking at some significant numbers there, I hesitate to say 24,000 as the tail in the google search could be skewed, but, "a lot" seems a fair assessment.
Virtually all deployed browsers support SSL, except a few special-purpose versions. The web servers supporting almost all of the web support SSL if they have keys installed. While many of them haven't bothered paying money for certified keys or doing self-signed keys, I'd be surprised if it's really as low as 1%. What's your source for that figure?
http://www.securityspace.com/s_survey/sdata/200305/index.html Total SSL servers 131,566. Now go to here: http://www.securityspace.com/s_survey/data/200305/domain.html Total webservers 10,432,910 (derived by 5280096 / 0.5061). That gives SSL penetration as 10,432,910 / 131,566 == 1.26% (Darn! I was wrong, it's slightly more than 1%, not less. I should be stoned and cursed!)
While only a small fraction of web pages, and a much smaller fraction of web bits transmitted, use SSL, that's appropriate, because most web pages are material the publisher wants the public to see, so eavesdropping isn't particularly part of the threat model, and even integrity protection is seldom a realistic worry.
Hmmm... You might say that, but I would have said it was the other way around! There is - surprisingly - not much of a threat model for eavesdropping of credit cards (and - shockingly - even less of an MITM threat model). It's easier for a crook to break in and hack the DB, and pick up tens of thousands than to haunt the net looking for an elusive 16 digit number out of a browser page. But, there is a big personal cost with reputational information. Few people would want to see my credit card info, but I can think of lots that would be keen on seeing my adult browsing, my gaming addition, or my participation in my kleptomaniacal therapy group, not to mention anything embarrassing I might get up to! What I find curious is why all those open source people worked so hard to build in the crypto to protect credit cards, but didn't want to protect anything else. I can understand Netscape programmers - they wanted to sell secure servers for cash. But I don't understand why Apache and KDE and Mozilla deliver software tuned to protect credit cards. It would make sense if they were all paid to do this by the credit card companies ... but they aren't, are they? What's their incentive?
(By contrast, eavesdropping protection and integrity protection are critical to telnet-like applications, so SSH is a big win.)
It's nice to have routine web traffic encrypted, so that non-routine traffic doesn't stand out, and so that traffic analysis is much harder, but there is a significant CPU hit from the public-key phase, which affects the number of pages per hour that can be served.
We run a dozen or more web servers here, and I can never tell the difference between the unprotected ones and the protected ones, so I'm not sure what to make of the argument that SSL should be reserved for "important credit card numbers". I think CPU has gotted so cheap that running out of CPU is a great sign of a successful business, no more. The last time I made a serious business decision based on CPU horsepower was back in 1989. We are almost at the point where raw PCs can do 1000 RSAs per second. Companies like Visa and Mastercard process in the order of 1000 - 10,000 transactions per second. Which means if they were using an efficient payment system - one or 2 RSAs per transaction - they could be now thinking about putting their entire crypto processing on one PC. Maybe it's only an issue if one is serving continuously... in which case, maybe one could either "use less crypto" like switch back to smaller keys - way more secure than no keys - or buy a faster box? -- iang