man in the middle, SSL

[Anne & Lynn Wheeler]

somewhat related 

Study Finds Bank of America SiteKey is Flawed
http://it.slashdot.org/it/07/02/05/1323243.shtml

Study Finds Security Flaws on Web Sites of Major Banks
http://www.nytimes.com/2007/02/05/technology/05secure.html?ref=business

The Emperor's New Security Indicators
http://www.usablesecurity.org/emperor/

from above:

We evaluate website authentication measures that are designed to protect users from man-in-the-middle, "phishing", and other site forgery attacks. We asked 67 bank customers to conduct common online banking tasks. Each time they logged in, we presented increasingly alarming clues that their connection was insecure. First, we removed HTTPS indicators. Next, we removed the participant's site-authentication image---the customer-selected image that many websites now expect their users to verify before entering their passwords. Finally, we replaced the bank's login page with a warning page. After each clue, we measured whether participants entered their passwords or withheld them.

... snip ...

somewhat the issue ... from previous posts in this thread:
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL

and recent post/thread from early last month on the subject
http://www.garlic.com/~lynn/2007b.html#53
http://www.garlic.com/~lynn/2007b.html#54

... originally SSL was going to prevent man-in-the-middle attack because the person
knew the website that they were going to talk to and the corresponding URL. They would
enter that URL into the browser and the browser would validate that the contacted website
was in fact the website for that URL (assuming the entered URL was HTTPS and not HTTP)

early on, SSL was perceived to be too expensive,  and so relegated it to just checkout/payment.
now the user entered URL with HTTP and the website wasn't validated ... so could be man-in-the-middle. at some point the user clicked on https (checkout/payment) button provided by the website. now instead of HTTPS validating that the user was talking to the webserver that they thot they were talking to ... HTTPS was validating that the webserver was whatever webserver that the webserver was claiming to be
(since the webserver was providing both the HTTPS URL and the SSL digital certificate).

so as the user convention of clicking on provided buttons proliferated ... the cracks/gaps widened between what webserver the user thot they were talking to and the webserver they might actually be talking to (since there was less & less a connection between what they thot of as a browser and the URLs that were being validated by SSL).

So one of the possible countermeasures was for a website to provide unique "something you know" authentication ... i.e. something hopefully only you knew (so you had higher degree of confidence that you were actually talking to the website you thot you were talking to. 

The problem was that if the communication was already talking to man-in-the-middle website impersonation ... there is nothing that would prevent the man-in-the-middle from impersonating the website to the consumer ... and impersonating the consumer to the actual website. Effectively, by definition for man-in-the-middle, the man-in-the-middle transparently passes communication in both directions (except possibly modifying URLs and internet addresses contained in the traffic as needed).

in effect, the mechanism is a countermeasure to simple website impersonation attacks ... but not to website man-in-the-middle attacks.

other refs
http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"?
http://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007

misc. past posts mentioning man-in-the-middle attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

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