4 ms·

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.

harshreality 12y ago
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 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)
- DeuceDaily 11y ago
  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.

harshreality 12y ago

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 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)

DeuceDaily 11y ago
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.