Thor Lancelot Simon  wrote:
>Can you please posit an *exact* situation in which a man-in-the-middle
>could steal the client's credit card number even in the presence of a
>valid server certificate?

Sure.  If I can assume you're talking about SSL/https as it is
typically used in ecommerce today, that's easy.  Subvert DNS to
redirect the user to a site under controller of the attacker.
Then it doesn't matter whether the legitimate site has a valid server
cert or not.  Is this the kind of scenario you were looking for?

>Can you please explain *exactly* how using a
>client-side certificate rather than some other form of client authentication
>would prevent this?

Gonna make me work harder on this one, eh?  Well, ok, I'll give it a try.
Here's one possible way that you might be able to use client certs to
help (assuming client certs were usable and well-supported by browsers).
Beware: I'm making this one up as I go, so it's entirely possible there
are security flaws with my proposal; I'd welcome feedback.

When I establish a credit card with Visa, I generate a new client
certificate for this purpose and register it with  When I
want to buy a fancy hat from, Amazon re-directs me to$29.99&item=hat
My web browser opens a SSL channel to Visa's web server, authenticating my
presence using my client cert.  Visa presents me a description of the item
Amazon claims I want to buy, and asks me to confirm the request over that
authenticated channel.  If I confirm it, Visa forwards payment to Amazon
and debits my account.  Visa can tell whose account to debit by looking
at the mapping between my client certs and account numbers.  If Amazon
wants to coordinate, it can establish a separate secure channel with Visa.
(Key management for vendors is probably easier than for customers.)

I can't see any MITM attacks against this protocol.  The crucial point is
that Visa will only initiate payment if it receives confirmation from me,
over a channel where Visa has authenticated that I'm on the other end,
to do so.  A masquerading server doesn't learn any secrets that it can
use to authorize bogus transactions.

Does this work?

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to