On 3 May 2011, at 13:30, Todd Willey wrote:
On Tue, May 3, 2011 at 5:39 AM, Dirk-Willem van Gulik
<dirk-willem.van.gulik@xxxxxxxxx> wrote:
On 3 May 2011, at 10:31, Soren Hansen wrote:
2011/5/3 Todd Willey<todd@xxxxxxxxxxxx>:
In a heavily load-balanced environment you'll probably want to terminate SSL before it gets
proxied to the actual api servers,
Why is that? It seems like a win to distribute as much processing as
possible, including SSL termination?
Because most load balancing vendors are either 1) convinced that they need to go up the stack and have gradually made it impossible to do blind socket LB - and insist on looking at headers and what not, or 2) is soo far out of touch and old that blind socket forwarding is not overly practical as the outdated means to inform the LB what to blindly forward where is just too painful.
I was thinking of hardware acceleration.
Aye, Agreed - though these days - once the intial DSA/RSA negotiation is done - the rest is getting less and less painful[1] in modern environments - and give its very cloudy nature - quite likely distributed with enough CPU spare cycles.
But yes - a bright vendor/standard would indeed do a clever pass through to the distributed boxes for at least the initial exchange; optionally facilitate session sharing and/or providing it in-line and after the exchange it could be informed of the session key and then do a bit more than just blind forwarding.
Dw.
Dw.
1: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
