The lack of HTTPS at Amazon: identifying items purchased via information leakage

You're posting with a throwaway account which has no credibility. This is not a source at all.

Right, but you get a redirect to the https login page with an http login URL.

An attacker can attempt phishing with HTML/JS injection on a HTTP page but an attacker cannot get a user to be looking at Amazon's real login page over http.

I think the problem here is the term ``SSL stripping'' was used and it may be kind unclear what MITM attacks is actually encompassed by it.

The OP wrote ``An attacker can easily steal passwords with SSL Stripping''. If OP meant he can easily steal passwords by basically a s/https/http on all urls on the page, OP's wrong. The attacker needs to create their own fake login page, present it to the victim, and hope the victim falls for it

Can that concern be quantified? Properly implemented (without extra-large DH parameters [no 3072 or 4096 bit params for EDH if your RSA key is 2048 bits], using ECDHE preferentially, and with a sufficient SSL session cache), extra processing should be minimal. Didn't Google quote something like low single digits? 3%? Of course, Google did a lot of work on optimizing their SSL layer, including pushing for higher initial window sizes in linux's tcp stack, and their work on SSL false start even though they later abandoned it.

For organizations that are doing SSL termination on their frontend webservers, it depends on their traffic flow: what percentage of page hits are new vs already established ssl sessions that can hit the cache. Different kinds of sites are going to have different traffic mixes that will affect that cost.

Does Amazon use the google strategy of software SSL termination, or do they use hardware like F5 terminators? Either way, they already have some ssl termination capability, since the secure parts of their website rely on it, so it's only a matter of beefing up existing capability rather than implementing it from zero. They may already have a lot of excess SSL termination capacity that they're not using.

If SSL everywhere always costs a company money, why did Google switch so early? I think there are benefits that at least partially compensate for increased infrastructure costs.

I think it's more likely that embedded resources from non-ssl external pages are blocking SSL deployment. Or Amazon has a bunch of hardcoded http://www.amazon.com links in different parts of their codebase, that have to be tracked down and fixed. Mixed content is what I think is blocking ssl deployment on most sites. Small sites that have switched to SSL-everywhere often haven't spent the time to do it right, and whether because their software has hardcoded http embedded links, or they're linking content from other sites, mixed content warnings are common. (Protip: //domain/path [without the initial http or https] is a protocol-relative link, if you need to link to a different host but keep the protocol the same)

ah, interesting. so the charitable, non-gratuitously-negative interpretation of the OP is that he or she is a very lazy summarizer. the uncharitable interpretation is that he or she uses deceptive rhetorical devices to bolster a weak point.