SSL would prevent it, Re: Internet security flaw exposes private data

We all read about the most recent Internet security flaw that exposes private data [1]. Without any action on their part, a number of AT&T smartphone users found themselves logged into Facebook, a popular social networking site, under user accounts other than their own. The problem was quickly attributed to "misrouting," a term that suggests that information took a wrong turn somewhere in the network.

It looks like AT&T did something wrong, but in terms of proxy server setup, not routing, and the company is in the process of fixing it. But Facebook should also share some concern with this, as it didn't consider the information tied to a user's account authentication to be important enough to protect with something stronger than clear text.

So, when we look closer, the sky is not falling.

With at least one authenticated end-point (the end-point server, as usual), SSL would NOT allow an AT&T caching server that sits in-between to have had a "correct" SSL session between the wrong two end-points. See A. Menezes et al., /Handook of Applied Cryptography/, CRC Press, New York, 1997.

This statement is true even if the AT&T caching server is able not only to modify packets but also to drop incoming packets and insert its own packets at will into the traffic, and do so in two-way communication without delay, becoming an active man-in-the-middle (which a passive, caching server is not).

This should not be confused with a phishing attack, where the end-user is tricked to go to (for example) paypal.fraud.com instead of paypal.com -- and the server end-point is already wrong, or a "bridge" attack where (without noticing it) the user goes to the wrong server before SSL starts -- and stays there after SSL starts. The second user did reach facebook.com and this would have been enough under one-point authenticated SSL to prevent the first user session to be hijacked (which is what happened) as it would not have the correct session keys.

This should also not be confused either with other attacks on privacy and security, that work in spite of SSL. For example, if SSL is used you may still be connected to the wrong site (eg, using a rogue certificate), and your traffic may still be read by others behind an SSL proxy, but you would not be connected to someone else's previous SSL session, not would your SSL session be usable by someone else.

These attacks, despite much confusion online in discussion lists [for example, see refs. 2 and 3], do not  break SSL nor have any bearing on the SSL being able to prevent the reported facebook case ("Internet security flaw exposes private data").

The AT&T problem that originated this security issue -- which, by all evidence, was not an attack -- would have been prevented by facebook requiring SSL. This may be particularly important for mobile devices,
where users may have less connection information available to verify.

And, google did the right thing now by making SSL the default for gmail.

REFERENCES:
[1] http://arstechnica.com/web/news/2010/01/facebook-att-play-fast-and-loose-with-user-authentication.ars

[2] http://www.listbox.com/member/archive/247/2010/01/sort/time_rev/page/4/entry/13:270/20100117153354:9FD73A7C-03A7-11DF-8606-4E77A52306B0/

[3] http://www.listbox.com/member/archive/247/2010/01/sort/time_rev/page/4/entry/11:270/20100118113841:EE029CD4-044F-11DF-868D-868DA52306B0/