Maybe It's Snake Oil All the Way Down

[Ian Grigg]

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