On Wed, Jul 13, 2011 at 8:20 PM, Craig <cr...@haquarter.de> wrote: >> I'm not sure if you're serious or not, but If another party as >> administrating the backend servers, it seems likely that you won't >> have the private key for the ssl certificate. > > Yea I am, I would't dare to write shitty semi-joke mails on Willy's list. >
No prob (and I hope no offense) > In a big company, the loadbalancer could be managed by the network team, > and the servers by the application team, that's what I meant; you will > have the keys. Making HTTPS connections to backends would be really > nice, because quite often you have rules on your webservers that will > redirect HTTP traffic to HTTPS ... which causes an endless loop, if you > terminate that traffic on the loadbalancer and send it via HTTP to your > backend, of course. Surely, you can add headers with the loadbalancer, > so that the backend knows if the connection is already secure or needs > to get redirected, but then there are sometimes also funny application > servers that still go nuts at you. Or your apache config is being send > to you by a managed hosting customer and you have to patch it all the > time for the header check. It's much nicer to just tell haproxy that > those backend servers are HTTPS instead of HTTP. Sure, it takes more > ressources, and might slow things down a bit, but if it's a system that > runs at 5% of available ressources anyways, you won't care much. Even if > so, you might rather invest 5000$ in hardware to keep the performance > as-is than to create a sucky workflow and/or piss off your customers > because you have a "sucky loadbalancer that cannot loadbalance https > properly and makes us change our apache config which took us three days > and no one pays us that precious time". > Surely, you could just layer-3 balance, but that takes a lot of features > away and you might have to run a caching instance like varnish or squid > running, too. OK, I see the use case. IMHO though, I'd like to see these things remain separate (I did learn my trade on unix, and that philosophy has stuck). I could see combining them if there's a compelling performance case, probably because of a shorter data pipeline, but SSL is the cpu here, not the extra memory copies or buffering (we'll just have to wait for some tests ;). > Some IT contracts suck. ;) > Yes, they do :) -- James Bardin <jbar...@bu.edu> Systems Engineer Boston University IS&T
