Re: General SSL vs. non-SSL Performance

Hi. Am 17-03-2016 16:55, schrieb Pavlos Parissis: On 17/03/2016 04:49 μμ, Nenad Merdanovic wrote: Hello Pavlos, On 3/17/2016 4:45 PM, Pavlos Parissis wrote: I am working(not very actively) on a solution which utilizes this. It will use www.vaultproject.io as central store, a generating

RE: General SSL vs. non-SSL Performance

>> Hm, I haven't tried Apache yet but would that be a huge benefit compared >> to a setup using nbproc> 1? > > I haven't tried it either, but yes, I would assume so. To be more specific: the number of TLS handshakes would probably be similar, especially in a nbproc>1 configuration, but when you

Re: General SSL vs. non-SSL Performance

On 18.03.2016 11:46, Willy Tarreau wrote: > Hi Christian, > > On Fri, Mar 18, 2016 at 11:31:57AM +0100, Christian Ruppert wrote: >> I also just stumbled over this: >> https://software.intel.com/en-us/articles/accelerating-ssl-load-balancers-with-intel-xeon-v3-processors >> Might be interesting

RE: General SSL vs. non-SSL Performance

> The "option httpclose" was on purpose. Also the client could (during a > attack) simply do the same and achieve the same result. I don't think > that will help in such cases. So what you are actually and purposely benchmarking are SSL/TLS handshakes, because thats the bottleneck you are trying

Re: General SSL vs. non-SSL Performance

Hello Pavlos, On 3/17/2016 4:45 PM, Pavlos Parissis wrote: > I am working(not very actively) on a solution which utilizes this. > It will use www.vaultproject.io as central store, a generating engine > and a pull/push mechanism in place. > > But, the current version of HAProxy doesn't support

RE: General SSL vs. non-SSL Performance

> Some customers may require 4096 bit keys as it seems to be much more > decent than 2048 nowadays. I've not come across any recommendations pointing in that direction, in fact 2048-bit RSA are supposed to be safe for commercial use until 2030. I don't think this is a real requirement from

Re: General SSL vs. non-SSL Performance

Hi Christian, On Wed, Mar 16, 2016 at 05:25:53PM +0100, Christian Ruppert wrote: > Hi Lukas, > > On 2016-03-16 16:53, Lukas Tribus wrote: > >>The "option httpclose" was on purpose. Also the client could (during a > >>attack) simply do the same and achieve the same result. I don't think > >>that

Re: General SSL vs. non-SSL Performance

Hi Cyril, On 2016-03-16 16:14, Cyril Bonté wrote: Hi all, replying really quickly from a webmail, sorry for the lack of details [...] I also ran 2 parallel "ab" on two separate machines against a third one. The requests per second were around ~70 r/s per host instead of ~140. So I doubt it's

Re: General SSL vs. non-SSL Performance

Hi Willy, On 2016-03-17 06:05, Willy Tarreau wrote: Hi Christian, On Wed, Mar 16, 2016 at 05:25:53PM +0100, Christian Ruppert wrote: Hi Lukas, On 2016-03-16 16:53, Lukas Tribus wrote: >>The "option httpclose" was on purpose. Also the client could (during a >>attack) simply do the same and

Re: General SSL vs. non-SSL Performance

Hello, On 3/16/2016 6:25 PM, Christian Ruppert wrote: > > Some customers may require 4096 bit keys as it seems to be much more > decent than 2048 nowadays. So you may be limited here. A test with a > 2048 bit Cert gives me around ~770 requests per second, a test with an > 256 bit ECC cert around

Re: General SSL vs. non-SSL Performance

Hi. Am 17-03-2016 11:51, schrieb Gary Barrueto: Hi. On Mar 16, 2016 10:06 PM, "Willy Tarreau" < Here I don't know. TLS handshakes are one large part of what made me think that we must go multi-threaded instead of multi-process over the long term, just because I want to be able to pin

Re: General SSL vs. non-SSL Performance

Hi Aleks, On 2016-03-16 15:57, Aleksandar Lazic wrote: Hi. Am 16-03-2016 15:17, schrieb Christian Ruppert: Hi, this is rather HAProxy unrelated so more a general problem but anyway.. I did some tests with SSL vs. non-SSL performance and I wanted to share my results with you guys but also

Re: General SSL vs. non-SSL Performance

On 2016-03-18 11:31, Christian Ruppert wrote: Hi Willy, On 2016-03-17 06:05, Willy Tarreau wrote: Hi Christian, On Wed, Mar 16, 2016 at 05:25:53PM +0100, Christian Ruppert wrote: Hi Lukas, On 2016-03-16 16:53, Lukas Tribus wrote: >>The "option httpclose" was on purpose. Also the client

Re: General SSL vs. non-SSL Performance

Hi Nenad Am 17-03-2016 19:27, schrieb Nenad Merdanovic: Hello Aleksandar On 3/17/2016 6:00 PM, Aleksandar Lazic wrote: Okay I'm now lost 8-O please can anyone help me to understand how the flow works. 1st Request client -> ssl handshake -> haproxy server 1 (tls ticket?!) 2nd Request Same

Re: General SSL vs. non-SSL Performance

Hi all, replying really quickly from a webmail, sorry for the lack of details > [...] > I also ran 2 parallel "ab" on two separate machines against a third > one. > The requests per second were around ~70 r/s per host instead of ~140. > So > I doubt it's a entropy problem. The issue is in your

Re: General SSL vs. non-SSL Performance

On 17/03/2016 12:26 μμ, Nenad Merdanovic wrote: > Hello Gary, > > On 3/17/2016 11:51 AM, Gary Barrueto wrote: >> >> While that would help a single server, how about when dealing with multi >> servers + anycast: Has there been any thoughts about sharing ssl/tls >> session cache between servers?

Re: General SSL vs. non-SSL Performance

Hi. On Mar 16, 2016 10:06 PM, "Willy Tarreau" < > > Here I don't know. TLS handshakes are one large part of what made me think > that we must go multi-threaded instead of multi-process over the long term, > just because I want to be able to pin some tasks to some CPUs. Ie when TLS > says

Re: General SSL vs. non-SSL Performance

2016-03-17 20:48 GMT+01:00 Aleksandar Lazic : > Hm I'm not sure if understand this right. > I will try to repeat just to check if I have understand it righ. > > http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#5.1-tls-ticket-keys > > # > frontend ssl > bind

Re: General SSL vs. non-SSL Performance

On 2016-03-17 00:14, Nenad Merdanovic wrote: Hello, On 3/16/2016 6:25 PM, Christian Ruppert wrote: Some customers may require 4096 bit keys as it seems to be much more decent than 2048 nowadays. So you may be limited here. A test with a 2048 bit Cert gives me around ~770 requests per second,

RE: General SSL vs. non-SSL Performance

On 2016-03-16 17:56, Lukas Tribus wrote: Some customers may require 4096 bit keys as it seems to be much more decent than 2048 nowadays. I've not come across any recommendations pointing in that direction, in fact 2048-bit RSA are supposed to be safe for commercial use until 2030. I don't

Re: General SSL vs. non-SSL Performance

Hello Aleksandar On 3/17/2016 6:00 PM, Aleksandar Lazic wrote: > Okay I'm now lost 8-O > > please can anyone help me to understand how the flow works. > > 1st Request > client -> ssl handshake -> haproxy server 1 (tls ticket?!) > > 2nd Request > Same client -> ssl handshake -> haproxy server 2

Re: General SSL vs. non-SSL Performance

On Fri, Mar 18, 2016 at 03:04:43PM +0100, Dennis Jacobfeuerborn wrote: > > You don't need, just use the proxy protocol : > > > >listen secure > > bind :443 ssl crt foo.pem process 2-32 > > mode tcp > > server clear 127.0.0.1:81 send-proxy-v2 > > > >frontend clear > >

General SSL vs. non-SSL Performance

Hi, this is rather HAProxy unrelated so more a general problem but anyway.. I did some tests with SSL vs. non-SSL performance and I wanted to share my results with you guys but also trying to solve the actual problem So here is what I did: haproxy.cfg: global user haproxy

Re: General SSL vs. non-SSL Performance

On 17/03/2016 04:49 μμ, Nenad Merdanovic wrote: > Hello Pavlos, > > On 3/17/2016 4:45 PM, Pavlos Parissis wrote: >> I am working(not very actively) on a solution which utilizes this. >> It will use www.vaultproject.io as central store, a generating engine >> and a pull/push mechanism in place.

Re: General SSL vs. non-SSL Performance

Hello Gary, On 3/17/2016 11:51 AM, Gary Barrueto wrote: > > While that would help a single server, how about when dealing with multi > servers + anycast: Has there been any thoughts about sharing ssl/tls > session cache between servers? Like how apache can use memcache to store > its cache or

RE: General SSL vs. non-SSL Performance

Hi Lukas, On 2016-03-16 16:53, Lukas Tribus wrote: The "option httpclose" was on purpose. Also the client could (during a attack) simply do the same and achieve the same result. I don't think that will help in such cases. So what you are actually and purposely benchmarking are SSL/TLS

Re: General SSL vs. non-SSL Performance

Hi. Am 16-03-2016 15:17, schrieb Christian Ruppert: Hi, this is rather HAProxy unrelated so more a general problem but anyway.. I did some tests with SSL vs. non-SSL performance and I wanted to share my results with you guys but also trying to solve the actual problem So here is what I did:

Re: General SSL vs. non-SSL Performance

Hi Christian, On Fri, Mar 18, 2016 at 11:31:57AM +0100, Christian Ruppert wrote: > I also just stumbled over this: > https://software.intel.com/en-us/articles/accelerating-ssl-load-balancers-with-intel-xeon-v3-processors > Might be interesting for others as well. So ECC and multi-threaded/process