Amazon is moving to HTTPS everywhere in this June. The whole website is a complex machinery with multiple components and it takes time to move those components to HTTPS.
It is actually worse than that. Given an active attacker one can easily steal passwords using SSL stripping attacks. Ebay is also affected. Cookie stealing also works.
Pretty much every mixed http/https setup ("encrypt only the login") is broken.
No. SSL stripping is an attack where you prevent a user from upgrading to an HTTPS connection. That isn't possible here.
Many sites have multiple tiers of authentication. For example viewing items to purchase is over HTTP but to actually checkout or manage your account requires you to go to HTTPS and reauthenticate on an HTTPS login page. Always. After this you are kept on HTTPS for the trusted actions. Amazon only does shopping over http but trusted actions are all HTTPS.
This has been amazons authentication scheme for years and it is actually the same as googles (where Google does have http assets, they force a reauth before going to https only stuff).
The most an attacker could do is inject code on http pages, annoyingly add things to cart, purchase items with 1 click purchase (inject javascript that clicks the button) and eavesdrop on all items purchased (quite serious).
BUT they cannot perform SSL stripping if Amazon doesn't do any auth over HTTP. An attacker could do some phishing like attacks to try to convince the user to put their password in at the wrong time, though.
An attacker can also replace an https:// login URL with an http:// one on a page sent via unencrypted connection. The http:// page can then be manipulated in any way.
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
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.
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.
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).
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.
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.
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.
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.
I wonder if the lack of HTTPS during normal browsing is a deliberate choice (one motivated by testing) or if it's only like that out of legacy (preservation of URLs). It's difficult to imagine all of the possible issues they may know about that we don't, given their scale.
The author mentions that removing the ref parameter would be a solution to one of the problems discussed in the article but I put forward that they could also just encrypt the value for transmission and store the information in plain on the backend. If they won't move to HTTPS then that should solve at least one of the issues.
I would imagine they ran the A/B tests on 99th percentile metrics and also on consumer behavior and decided that having the HTTPS enabled by default would result in less revenue/growth/etc
I'd imagine with the number of requests they make to various analytics, internal services etc it is not a super simple migration.
HTTPS is pretty fast now with SPDY (and soon HTTP/2) but there is no avoiding the fact that is slows down that first page load ever so slightly. No doubt they have studied this carefully and opted for maximum speed, as this maximizes income.
My wild guess is processing costs. With the amount of traffic they see, encrypting every page of every item someone looks at could potentially be very costly.
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)
Low single digit could easily be viewed as significant. Given this scenario, it would be easy to guess google wasn't basing their decision entirely off cost. You'd have no real idea in either case unless you were involved in the decision making.
In an era where American ISPs charge extra to not spy on your non-encrypted traffic, it seems odd that Amazon doesn't care... improving the non-Amazon ads that you receive surely causes Amazon to lose money.
There's also some fascinating anti-showrooming technology out there which monitors when you look at things over the store's guest wifi network. Browsing products on Amazon still isn't encrypted (as the article identifies) and neither is "Add to Cart".
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.
I had a scare regarding this a few days ago. I was searching for a Bose airline adapter on DuckDuckGo and clicked the top result without looking at the URL. [1] I ended up hitting some page on www.casselsonline.com that exactly mirrored Amazon's website right down to suggested items and everything. I didn't even notice I wasn't on amazon.ca until I went to sign in and found the certificate broken.
Couldn't find a place to report URLs on DDG, so I reported them to Google.
It helps to have something like HTTP Switchboard[1] installed on your browser, with per-domain rules. When I click the result, I get a white page since HTTPSB blocks the CSS/JS/cookies etc by default on domains that I haven't explicitly whitelisted.
With an HTTP connection, it becomes easy for an attacker in the middle to prompt the user to re-enter their password and have it re-transmitted in the clear.
