Microsoft just released an advisory to this in the last couple days, I have been following this since October last year. http://support.microsoft.com/kb/977377
The basic premise of the attack is a man in the middle attack using SSL renegotiation. Here is what a basic attack would look like.
When Jimmy connected to the wireless network Sam (the attacker) poisoned his ARP cache and now all of Jimmy’s traffic is flowing through Sam’s laptop and then out to the internet.
When the connection to https://e-banking.com came through Sam’s laptop he held back those packets (Session #1) and opened a new connection to https://e-banking.com (Session #2). Sam then completes a full TLS handshake and triggers a renegotiation of the tunnel (This is a standard function of the protocol).
Then Session #1 that was held back is released to https://e-banking.com, this is done over the encrypted Session #2 tunnel. The server receives the Session #1 connection and associates the session with Sam (attacker) and not Jimmy (again this is expected behavior of the protocol, the server was expecting a renegotiation and a new connection looks exactly the same).
At this point Jimmy has no idea what has happened his browser still says he is connected to the site and that the SSL certificate is trusted.
This is overly simplified example of what could be done in a case like this.
Jimmy sends a get command to do a fund transfer.
GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=1234567 HTTP/1.1 Cookie: victimscookie
Sam gets this or any other packet with the cookie in it and adds the following.
GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=9876543 HTTP/1.1 X-Ignore-This:
After the X-Ignore-This Sam adds the information from Jimmy’s packet, and ends up with this when it arrives at the server.
GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=9876543 HTTP/1.1 X-Ignore-This: GET /bank.php?send=1000;dest=1000;send_account=1234567;dest_account=1234567 HTTP/1.1 Cookie: victimscookie
The web server ignores the legitimate request because of the X-Ignore-This but processes the other GET request and uses the Cookie for authentication.
This exact setup was just proven using twitter by a researcher and they were able to get twitter to ‘tweet’ back the usernames and passwords from the high jacked sessions.
Here is a link to the story about the Twitter attack, http://www.theregister.co.uk/2009/11/14/ssl_renegotiation_bug_exploited/