4 ms·
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 i
by bluesmoon 16y ago
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?
- walkon 16y agoRequire SSL on any request who's response sends a set-cookie http header. Leave it out for the non-sensitive request/responses.
- santry 16y agoYou'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.
- deleted 16y ago[deleted]
- EricButler 16y agoWhen Gmail switched on SSL for everyone earlier this year they added "no additional machines" (http://unblog.pidster.com/imperialviolet-overclocking-ssl 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.
- qeorge 16y agoWhat 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/ https://panopticlick.eff.org/
- bl4k 16y agoyep 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
- geoffbp 16y agointeresting info in that url, thanks
- pak 16y agoPeople 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.)
- Groxx 16y agoHow 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.
- psadauskas 16y agoThat 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.