Hacker News new | past | comments | ask | show | jobs | submit login

Why would it be any different on Google's scale? I mean, presumably the solution is the same install-ssl-plugin-and-point-it-to-a-cert fare that you would go through for any web server. Am I missing something here?



I think you're missing how expensive it is to make SSL work on a large scale. That being the reason it isn't the default everywhere.


Does the cost of SSL grow super linearly when you scale up?


Super linearly is a new term to me, but it doesn't grow linearly. However, it does grow, and Google is huge. The cost, in terms of labor, focus bandwidth, and money, is large at their scale.


The cost of TLS is linear in every way I can think of. The TLS handshake is basically constant overhead--in space and time--and O(n)--in space and time--transform of the actual data.


The constant factors are high relative to simply serving HTML, especially on a site that tracks non-encrypted performance down to the millisecond.


Sure, but talking about it being expensive 'on a large scale' is a bit odd - since revenue/profits also grow with scale. It seems to imply a greater than linear growth in costs.


Google has a completely different back-end architecture than a dinky website, and the costs come from the sophistication and complexity of the systems required at that scale.

Google has multiple data centers, dedicated caching and web clusters, complex internal network routing and load-balancing, etc. Then there's stuff like javascript and image hosting optimizations that you've got to make sure work without triggering SSL warnings across thousands of servers. Enabling SSL support for something like Googe search could potentially touch tens of thousands of systems. In short, maybe it's as simple as flipping a bit to enable SSL on the web farm, but I doubt it. There's probably a massive amount of internal engineering and organization behind the change, and that cost is what you're neglecting.

To give you perspective, it's trivial to enable SSL on a single-box website; it can be done in an afternoon. When we turned it on at Justin.tv, it took a few days (let's call it a week) of initial work, and ongoing maintenance costs to make sure that SSL sessions weren't breaking as we made improvements across the site. The costs go up as you get bigger and more complicated.


If it takes 4 hour to get SSL working for a site with 5,000 users then linear growth to a site with 250,000,000 users is 50,000 hours. IMO, google can get SSL working in less than 50,000 hours.


spideroak.com has always been an all SSL site, and there are a few additional annoyances:

- You need a cert for example.com, and maybe a wildcard cert for .example.com, and for any additional levels of subdomains such as *.{x,y,z,etc}.example.com.

- Not all search engines seem to credit links to http://example.com/ and https://example.com equally.

- Even modern browsers sometimes abort downloads over SSL silently, without even an indication to the user that the download failed (despite sending a content-length header.) That's the really frustrating one.


I'm sure that the SEO problem isn't a big deal for Google. ;)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: