Hacker News Reader

Comment by bluesmoon | Hacker News Reader

SSL is bad for the environment because it requires far more server side hardware... Well, I'm only partially serious about the environment thing, the question is, how can internet companies make it commercially viable to use SSL for everything? The added hardware and power costs make each user way more expensive, possibly to the point where they may not actually be worth it.

An alternative is to bind the user's session to their IP address, but that isn't fool proof either because of NAT, DHCP and certain big ISPs that tend to change IPs on the fly.

What cost-effective solution would you suggest?

View on HN

When Gmail switched on SSL for everyone earlier this year they added "no additional machines" (http://unblog.pidster.com/imperialviolet-overclocking-ssl).

Regarding IPs, there's a bigger issue here. People are used to being able to shut their laptop at home and open it back up at work without having to re-authenticate all their browser tabs. If you filter by IP this breaks. SSL requires no changes to user behavior.

What about pairing the auth token with a browser fingerprint? [1]

It would make it harder to troll an open network for random victims, and wouldn't annoy the user.

[1] Perhaps a hash based on something like this https://panopticlick.eff.org/

yep then you extend it to something as simple as having a second ID in localStorage or a flash cookie

then the next version of this plugin just spoofs all of those parameters as well

the only solution[1] is SSL and client certificates

[1] in the case of being on the same network

interesting info in that url, thanks

People bring up the Google stat, but you have to remember they have incredible engineering resources so they probably optimize in many features every day without adding additional machines. That doesn't mean every dude with a LAMP stack out there can turn on SSL and expect the same performance, just that it's possible with mongo manpower and talent to make it work. (Google doesn't even release the details of their web stack so comparing their stat is apples and oranges.)

How many web servers do you know of which are CPU bound, and not through massive code stupidity, and not I/O (in some manner - waiting on SQL, disk access, bandwidth)? Encryption can run while other threads are waiting for a response.

In general, it's a negligible cost; it adds a very minor delay compared to latency / transfer time, and uses CPU otherwise highly unlikely to be pegged. If you're pushing threading limits / CPU usage limits, you're probably inches from needing new hardware anyway, and SSL should be considered part of the cost of running a web server.

It's not completely negligible--even if CPU usage is negligible, it does add latency during SSL negotiation that might be unpreferable for some apps. The testing burden is a lot higher because one wrong link to http:// in CSS, HTML, or AJAX will cause big scary messages. And there is the IP address problem, you can't vhost as most people with Apache like to do.

That may have been true 10 years ago, but the overhead of SSL for CPU is almost nothing, and only a few ms of latency. Web applications are mostly IO and memory bound, anyways. We should be using SSL all the time, by default. There's no reason not to, at this point, aside from certificate authorities.

Require SSL on any request who's response sends a set-cookie http header. Leave it out for the non-sensitive request/responses.

You'd still be able to get the cookie when the client sends it bnack to the server on subsequent, non-SSL requests.

It's gotta be SSL all the time.

Reply on news.ycombinator.com