On Fri, Jun 17, 2016 at 09:50:15PM +0200, Jochen Spieker wrote: > > Admittedly, one of the main issues with HTTPS is the number of > handshakes your hardware can do per second. That probably isn't a > problem for the CD image download server that we are discussing here. > But for (non-distributed) sites that serve a huge number of requests > (think tens of thousands of requests per second) and (unlike Google) use > off-the-shelf hardware and software that's a different issue. I am > working on such a site and our customer has to spend big bucks for our > load balancers (F5 BIG IP) which terminate SSL connections in our > environment.
In my experience, the majority of people buying F5's load balancers are doing so because they don't have the expertise on staff to do configuration management of commodity Linux boxes running either an ipvs based system like ldirector or a user-mode loadbalancer like haproxy. Rack unit for rack unit, a Xeon E5-26xx v4 with a pair of dual-port 10gig ethernet cards will outperform F5 hardware costing 4-5x as much, while being fully supported by Debian. Debian's record on patching security holes is at least on par with and arguably better than F5's. The decision to terminate SSL on a load balancer vs on web servers in the backend is application-specific, but in many cases the backend termination is superior. Hundreds of thousands of requests per second can be handled on such commodity hardware, properly configured. In any case: most users in most situations are running low-intensity servers on machines that are at least as good as a Raspberry Pi model B, and thus using SSL on every applicable connection is a privacy boon, rather than a performance worry. -dsr- -- https://randomstring.org/~dsr/eula.html is hereby incorporated by reference. there is no justice, there is just us.
