[ivanr]

Once the attacker hijacks the plaintext HTTP connection, she can pretty much do whatever she wants with the user. Of course, that's provided we're talking about a casual user, who isn't going to pay much attention to the HTTPS indicators.

Thus, the first leg of the traffic, between the victim and the MITM attacker is forever unencrypted. The second leg, between the attacker and the servers can be encrypted; it's not going to impact the attacker's capabilities in any way.

The attacker doesn't need to create their own fake login page, etc, because she can simply proxy all traffic from and to Amazon's servers.

[steakejjs]

Not all traffic. Amazon has a separate SecureOnly cookie for access to their trusted pages that isn't sent over HTTP. Without that cookie not all traffic can be proxied.

[ivanr]

If Amazon has any secure cookies, they're not going to affect this particular attack. The traffic leg between the attacker and Amazon's servers can be encrypted, which means that she will receive the secure cookies. Because the leg between the victim and the attacker is not encrypted, the attacker simply rewrites the cookies to remove the "secure" flag. Thus, from the perspective of the victim the cookies are not secure.

To summarise, the attacker injects herself into the traffic stream, fully controlling the Amazon side of the communication, and forwards traffic to the victim rewriting as appropriate. The account compromise occurs when Amazon asks the victim for the password (as they do before each purchase) and the attacker captures the password (because it will have been sent to her, rather to Amazon).

[steakejjs]

Sounds like we were always on the same page...

I never said an attacker can't do this. I'm saying an attacker can't do a s/https/http and have a user end up at an HTTP login page, where the attacker can sniff credentials.

[nitrogen]

The attacker operates the http login page as a MITM. If they can mangle http traffic, they can run a full MITM.

[coderzach]

yes they can. They make the secure login connection, and terminate it themselves, then route what they received along to the user with s/https/http.

[falcolas]

All the MITM has to do is relay the traffic to the correct secure location, passing the credentials passed via the compromised HTTP connection, and the user's entire account is compromised.

Remember: HTTPS does not ensure the identity of the client.

[steakejjs]

Relay what credentials from the HTTP connection ? There are none...

It sounds like you are talking about creating a phishing page and injecting it, hoping the user enters their credentials, and stealing them. I already said this was possible.

[falcolas]

User browses Amazon normally, MITM proxy simply alters response links containing "https" back to http, keeping track of what links were downgraded so it can start relaying between http and https when one of those links is hit.

User requests login page over http

HTTP request is intercepted, and relayed over https to amazon

https response from Amazon is modified to show http links, and presented back to the user

User fills in credentials and submits request over http

Request is intercepted, and relayed over https back to Amazon

MITM now has all credentials.

Doesn't require any special tools, or a phishing page, just a spot between Amazon and the user, and the ability to re-write responses from https back to http.

HTTPS with a HSTS setting would mitigate this, since the browser would refuse to request the HTTP page if the user had ever successfully visited https://www.amazon.com before.