SSL, client certs, and MITM (was WYTM?)

[Anne & Lynn Wheeler]

At 05:08 PM 10/22/2003 -0400, Tom Otvos wrote:

>The CC number is clearly not hidden if there is a MITM.  I think the "I 
>got my money so who cares
>where it came from" argument is not entirely a fair 
>representation.  Someone ends up paying for
>abuses, even if it is us in CC fees, otherwise why bother encrypting at 
>all?  But that is besides
>the point.

the statement was SSL domain name certificate is

1) am i really talking to who I think I'm talking to
2) encrypted channel

obviously #1 addresses MITM (am i really talking to who I think I'm talking 
to).

The issue for CC is that it really is a "shjared secret" and is extremely 
vulnerable ... as I've commented before

1) CC needs to be in the clear in a dozen or so business processes
2) much simpler to harvest a whole merchant file with possibly millions of 
CC numbers in about the same effort to evesdrop one off the net (even if 
there was no SSL) return on investment .... for approx. same amount of 
effort get one CC number or get millions
3) all the instances in the press are in fact involved with harvesting 
large files of numbers ... not one or two at a time off the wire
4) burying the earth in miles of crypto still wouldn't eliminate the 
current shared-secret CC problem

slightly related .... security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

so the requirement given the X9 financial standards working group X9A10
http://www.x9.org/

was to preserve the integrity of the financial infrastructure for all 
electronic retail payment (regardless of kind, origin, method, etc). The 
result was X9.59 standard
http://www.garlic.com/~lynn/index.html#x959

which effectively defines a digitally signed, authenticated transaction 
.... no certificate required ... and the CC number used in X9.59 
authenticated transactions shouldn't be used in non-authenticated 
transactions. Since the transaction is now digitally signed transactions 
and the CC# can't be used in non-authenticated transactions .... you can 
listen in on X9.59 transactions and harvest all the CC# that you want to 
and it doesn't help with doing fraudulent transactions. In effect, X9.59 
changes the business rules so that CC# no longer need to be treated as 
shared secrets.

misc. past stuff about ssl domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

misc. past stuff about relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

misc. past stuff about using certificateless digital signatures in radius 
authentication
http://www.garlic.com/~lynn/subpubkey.html#radius

misc. past stuff about using certificateless digital signatures in kerberos 
authentication
http://www.garlic.com/~lynn/subpubkey.html#kerberos

misc. fraud & exploits (including some number of cc related press 
announcements)
http://www.garlic.com/~lynn/subtopic.html#fraud

some discussion of early SSL deployment for what is now referred to as 
electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com