[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

man-in-the-middle attacks



>Date: Mon, 15 Jul 1996 12:07:53 -0400
>To: simsong@vineyard.net (Simson L. Garfinkel)
>From: Carl Ellison <cme@cybercash.com>
>Subject: man-in-the-middle attacks
>Cc: Tom Weinstein <tomw@netscape.com>, ssl-talk@netscape.com
>
>At 02:00 AM 7/15/96 -0400, Simson L. Garfinkel wrote:
>>Re: Diffie-Hellman SSL Handshake
>
>>Why not use a key-splitting protocol to defeat man-in-the-middle? (I send
>>you 1/2 my public value, you send me 1/2 your public value, I send you the
>>second 1/2 of my public value, and you send me the second 1/2 of yours.)
>
>This is subject to attack:
>
> Bellovin and Merritt, ``An Attack on the Interlock Protocol When Used for
>Authentication'', IEEE Trans. Inf. Theory 40:1, Jan 1994. 
>
>under which one of the two ends loses communication while the other end ends
>up suckered.
>
>I am presenting a paper at USENIX Security next week with a protocol for
>certificate-less verification of the person on the other end, but it
>requires you to have a body of common knowledge (shared secrets) between the
>ends.
>
>I haven't proved it, but it should be easy to prove that if you have no
>common knowledge between the two ends, it is impossible to prevent a
>man-in-the-middle attack.  The proof might run like:
>
>Alice connects to Bob but Mallet is in the middle, modifying the message
>stream, sometimes inserting answers, sometimes passing things through and
>just watching what is written:
>
>        Alice <-> Mallet <-> Bob
>
>and that's bad.
>
>Alice connects to Bob who has delegated all correspondence duties to Carol,
>including use of his signature key.  Carol filters Bob's correspondence and
>sends along only selected items, answering the others herself:
>
>        Alice <-> Carol <-> Bob
>
>and that's good.
>
>Since the names Mallet and Carol are arbitrary, I'm allowed to switch them.
>
>A proper certificate is shared knowledge between the parties -- but you need
>to know the person at the end so that you know that what you have is his
>(her) certificate.  To know that, you need to have some preexisting mental
>construct for him or her to test this certificate against.  If you know
>nothing about that person, you have no clue whose certificate you might
>have.  For example, you might have a certified key exchange allowing you a
>private channel to Bob but Bob might be re-encrypting and passing all
>traffic through to David so that you're really talking with David, through
>Bob's certificate.  Since you've never met either Bob or David, you have no
>clue from the message traffic who it is you're really talking to.  Bob can
>translate all messages, exchange "David" with "Bob", etc.
>
>        Alice <=> Bob <-> David
>
>In this example, Alice and Bob have a certified connection.  If Bob happens
>to have the same class certificate Alice does (e.g., Alice a merchant, Bob a
>merchant and a user, David a user) then both connections can be certified,
>with neither Alice nor David knowing that they're really dealing with each
>other -- with Bob just listening in.
>
>        Alice <=> Bob <=> David
>
>For electronic commerce, this might result in capture of sensitive
>information (CC #s, SSNs, consumer profile, ...).  For conversations, Bob
>could be a voyeur and get his kicks out of connecting David to an anonymous
>phone sex line while he (Bob) just listens in.
>
> - Carl
>
>+--------------------------------------------------------------------------+
>|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
>|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
>|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
>|Reston, VA 22091              Tel: (703) 620-4200                         |
>+--------------------------------------------------------------------------+
>
>
>