SSL best option for new deployments
Been using haproxy for some time. but have not used it with SSL yet. What is the best option to implement SSL? There seems to be several options, some requiring 1.5 (which isn't exactly ideal as 1.5 isn't considered stable yet). I do need to route based on the incoming request, so decode before haproxy as opposed to the MODE TCP options. Also, would like persistent between client and haproxy, but allow different back-ends per request. I do need to preserve the IP address of the original client. So either transparent (is that possible when going through stunnel or other and haproxy on the same box), or X-Forwarded-for or similar added.
Re: SSL best option for new deployments
On 12/13/2011 09:02 PM, John Lauro wrote: Been using haproxy for some time… but have not used it with SSL yet. I do need to preserve the IP address of the original client. So either transparent (is that possible when going through stunnel or other and haproxy on the same box), or X-Forwarded-for or similar added. You should probably put stud (https://github.com/bumptech/stud) in front of haproxy. It supports sendproxy protocol from haproxy 1.5, supports ipv6 and scaling out. There's also a patch for sendproxy protocol that pplies to haproxy 1.4. However, you shouldn't be afraid of running haproxy 1.5-devXX, it is really, really very stable. Best regards, Brane
RE: SSL best option for new deployments
I've been using stunnel with the X-Forwarded-For patch. Is stud preferable to stunnel for some reason? David -Original Message- From: Brane F. Gračnar [mailto:brane.grac...@tsmedia.si] Sent: Tuesday, December 13, 2011 1:36 PM To: John Lauro Cc: haproxy@formilux.org Subject: Re: SSL best option for new deployments On 12/13/2011 09:02 PM, John Lauro wrote: Been using haproxy for some time… but have not used it with SSL yet. I do need to preserve the IP address of the original client. So either transparent (is that possible when going through stunnel or other and haproxy on the same box), or X-Forwarded-for or similar added. You should probably put stud (https://github.com/bumptech/stud) in front of haproxy. It supports sendproxy protocol from haproxy 1.5, supports ipv6 and scaling out. There's also a patch for sendproxy protocol that pplies to haproxy 1.4. However, you shouldn't be afraid of running haproxy 1.5-devXX, it is really, really very stable. Best regards, Brane
Re: SSL best option for new deployments
On 12/13/2011 10:43 PM, David Prothero wrote: I've been using stunnel with the X-Forwarded-For patch. Is stud preferable to stunnel for some reason? Stunnel usually uses thread-per-connection architecture - as you probably know this programming model has serious scaling issues. Stud is single-threaded and runs as single-master/multiple-workers process, meaning that it can efficiently utilize power of multi-core cpus without context-switching overheaded resulting from hundreds (possibly thousands) of threads competing for cpu time slice. Stud is implemented on top of libev, one of the most efficient event loops available. It also uses much less memory than stunnel (openssl = 1.x.x). Best regards, Brane
RE: SSL best option for new deployments
Interesting. Found this with google comparing the two (only a few months old): http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html In summary, performance appears to be close as long as you only have 1 core, but stud scales better with multiple cores. However, as noted in the replies, newer version of stunnel probably perform better. -Original Message- From: Brane F. Gračnar [mailto:brane.grac...@tsmedia.si] Sent: Tuesday, December 13, 2011 5:21 PM To: David Prothero Cc: John Lauro; haproxy@formilux.org Subject: Re: SSL best option for new deployments On 12/13/2011 10:43 PM, David Prothero wrote: I've been using stunnel with the X-Forwarded-For patch. Is stud preferable to stunnel for some reason? Stunnel usually uses thread-per-connection architecture - as you probably know this programming model has serious scaling issues. Stud is single-threaded and runs as single-master/multiple-workers process, meaning that it can efficiently utilize power of multi-core cpus without context-switching overheaded resulting from hundreds (possibly thousands) of threads competing for cpu time slice. Stud is implemented on top of libev, one of the most efficient event loops available. It also uses much less memory than stunnel (openssl = 1.x.x). Best regards, Brane
Re: SSL best option for new deployments
And stud is still young and does not have all the features stunnel owns ;) cheers On Tue, Dec 13, 2011 at 11:43 PM, John Lauro john.la...@covenanteyes.com wrote: Interesting. Found this with google comparing the two (only a few months old): http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html In summary, performance appears to be close as long as you only have 1 core, but stud scales better with multiple cores. However, as noted in the replies, newer version of stunnel probably perform better. -Original Message- From: Brane F. Gračnar [mailto:brane.grac...@tsmedia.si] Sent: Tuesday, December 13, 2011 5:21 PM To: David Prothero Cc: John Lauro; haproxy@formilux.org Subject: Re: SSL best option for new deployments On 12/13/2011 10:43 PM, David Prothero wrote: I've been using stunnel with the X-Forwarded-For patch. Is stud preferable to stunnel for some reason? Stunnel usually uses thread-per-connection architecture - as you probably know this programming model has serious scaling issues. Stud is single-threaded and runs as single-master/multiple-workers process, meaning that it can efficiently utilize power of multi-core cpus without context-switching overheaded resulting from hundreds (possibly thousands) of threads competing for cpu time slice. Stud is implemented on top of libev, one of the most efficient event loops available. It also uses much less memory than stunnel (openssl = 1.x.x). Best regards, Brane
Re: SSL best option for new deployments
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 13 décembre 2011, vers 23:43, John Lauro john.la...@covenanteyes.com disait : Found this with google comparing the two (only a few months old): http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html In summary, performance appears to be close as long as you only have 1 core, but stud scales better with multiple cores. However, as noted in the replies, newer version of stunnel probably perform better. There is an updated benchmark here: http://vincent.bernat.im/en/blog/2011-ssl-benchmark-round2.html Now, stunnel and stud have the same performance. For stunnel, you need to use OpenSSL 1.0.0c or later to fix a performance problem. With hyperthreading, I even got better results with stunnel. If you use stunnel, use at least 4.45. It features sendproxy support. -- Vincent Bernat ☯ http://vincent.bernat.im Use uniform input formats. - The Elements of Programming Style (Kernighan Plauger)
Re: SSL best option for new deployments
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 13 décembre 2011, vers 23:20, Brane F. Gračnar brane.grac...@tsmedia.si disait : It also uses much less memory than stunnel (openssl = 1.x.x). stunnel has also enabled the SSL_MOD_RELEASE_BUFFERS on recent versions (since 4.45). I think this would amend the difference with stud. -- Vincent Bernat ☯ http://vincent.bernat.im Make sure every module hides something. - The Elements of Programming Style (Kernighan Plauger)
