HAProxy 1.8 takes too long to update new config

2017-12-27 Thread Robin Anil
In Http/2 mode with threads enabled, updating the config on a live serving
haproxy server takes several minutes.

If I turn this off, the update of config is near instantaneous.

The config change itself is just adding a newline in the file. So it feels
like haproxy is waiting for connections to close down or something...

My question is, is this a known behavior? Definitely not desired, not
unless the stats page has some indicator that update is happening and
connections are being migrated over or something.

Robin


[PATCH] BUILD/SMALL Fixed build on macOS with lua

2017-12-27 Thread Kirill A. Korinsky
Last macOS hasn't support export-dynamic, just remove it
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 2acf5028..19234897 100644
--- a/Makefile
+++ b/Makefile
@@ -630,7 +630,7 @@ check_lua_inc = $(shell if [ -d $(2)$(1) ]; then echo 
$(2)$(1); fi;)
 
 BUILD_OPTIONS   += $(call ignore_implicit,USE_LUA)
 OPTIONS_CFLAGS  += -DUSE_LUA $(if $(LUA_INC),-I$(LUA_INC))
-LUA_LD_FLAGS := -Wl,--export-dynamic $(if $(LUA_LIB),-L$(LUA_LIB))
+LUA_LD_FLAGS := $(if $(LUA_LIB),-L$(LUA_LIB))
 ifeq ($(LUA_LIB_NAME),)
 # Try to automatically detect the Lua library
 LUA_LIB_NAME := $(firstword $(foreach lib,lua5.3 lua53 lua,$(call 
check_lua_lib,$(lib),$(LUA_LD_FLAGS
-- 
2.15.1




Re: bug: mworker unable to reload on USR2 since baf6ea4b

2017-12-27 Thread William Lallemand
On Wed, Dec 27, 2017 at 10:21:25PM +0100, Lukas Tribus wrote:
> Hello Pieter,
> 
> 
> On Tue, Dec 26, 2017 at 1:08 AM, PiBa-NL  wrote:
> > Hi Lucas, William,
> >
> > I've made a patch which 'i think' fixes the issue with fclose called 'to
> > often?'.
> > Can you guys verify?
> 
> I can confirm the patch fixes the issue reported; whether it does it
> "the correct way" - I don't know ...
> 
> Maybe William can take a look?
> 

Hi Guys,

The patch seems to fix the issue, but we don't want to reproduce the same
problem again and again, it won't fix everything in my opinion.

I wasn't enthusiastic about the idea of having the pipe of the master and the
poller using the fd 0, 1 and 2; it's confusing during the debugging.
And we don't want to be surprised by libraries trying to write on the FD 1 or 2
for debugging. (glibc or openssl for example)

I think that's better to open /dev/null and dup2 with 0, 1, 2 so we won't have 
any
surprise with an fprintf(stderr, "..  anywhere in the code.

What's difficult with this, is that we need to display the error after the
chroot for the setuid and setgid, and we don't have access to /dev/null after
this, maybe we could open /dev/null in the master, do the chroot/setuid/setgid
and then do the dup2 in the worker.

-- 
William Lallemand



Re: HTTP/2 Termination vs. Firefox Quantum

2017-12-27 Thread Lucas Rolff
My small site is basically a html page with two pages (home and about for 
example), each page contains basic markup, some styling and some JavaScript, 
switching pages tends to replicate the issue every now and then (differs a bit 
how often it happens, but possibly every 20-30 request or so)

I’m single user being able to replicate the issue, no other traffic than myself

So the test scenario is fairly easy to replicate in that sense

Tomorrow I’ll check if I can replicate the same issue in other browsers as well

I haven’t been able to replicate it with curl yet and haven’t tried with 
nghttp, I’ll continue to troubleshoot meanwhile, but it’s a bit odd it happens

Best regards,

Get Outlook for iOS

From: lu...@ltri.eu  on behalf of Lukas Tribus 
Sent: Wednesday, December 27, 2017 10:51:01 PM
To: Lucas Rolff
Cc: haproxy@formilux.org
Subject: Re: HTTP/2 Termination vs. Firefox Quantum

Hello Lucas,



On Wed, Dec 27, 2017 at 9:24 PM, Lucas Rolff  wrote:
> Can't even compose an email correctly..
>
> So:
>
> I experience the same issue however with nginx as a backend.
>
> I tried enabling “option httplog” within my frontend, it's rather easy for
> me to replicate, it affects a few percent of the traffic.

So you have this html endpoint and you hit F5 in FF Quantum until you
can see the issue or how is it that you actually reproduce? Does this
occur in a idle test environment as well, or do you need production
traffic to hit this issue?



> I have a site, with a total of 3 requests being performed:
>
> -  The HTML itself
> - 1 app.css file
> - 1 app.js file

Please clarify:

- if any of those responses are cached (or if they are uncachable) and
if they use any kind of revalidation (If-modified-since --> 304)
- if any of those files are compressed, by haproxy or nginx, and which
compression is used
- the exact uncompressed content-length of each of those responses
- the exact client OS
- is Quantum a 32 or 64 bit executable on the client?
- is haproxy a 32 or 64 bit executable?
- can you run this repro in debug mode on show the output when the issue occurs?
- RTT and bandwidth between server and client (race conditions may
depend on specific network performance - not every issue is
reproducible on localhost)
- confirm that FF sandboxing is not affecting this issue by lowering
security.sandbox.content.level to 2 or 0 in about:config (then restart
FF) - don't forget to turn it back on




Thanks,
Lukas


Re: HTTP/2 Termination vs. Firefox Quantum

2017-12-27 Thread Lukas Tribus
Hello Lucas,



On Wed, Dec 27, 2017 at 9:24 PM, Lucas Rolff  wrote:
> Can't even compose an email correctly..
>
> So:
>
> I experience the same issue however with nginx as a backend.
>
> I tried enabling “option httplog” within my frontend, it's rather easy for
> me to replicate, it affects a few percent of the traffic.

So you have this html endpoint and you hit F5 in FF Quantum until you
can see the issue or how is it that you actually reproduce? Does this
occur in a idle test environment as well, or do you need production
traffic to hit this issue?



> I have a site, with a total of 3 requests being performed:
>
> -  The HTML itself
> - 1 app.css file
> - 1 app.js file

Please clarify:

- if any of those responses are cached (or if they are uncachable) and
if they use any kind of revalidation (If-modified-since --> 304)
- if any of those files are compressed, by haproxy or nginx, and which
compression is used
- the exact uncompressed content-length of each of those responses
- the exact client OS
- is Quantum a 32 or 64 bit executable on the client?
- is haproxy a 32 or 64 bit executable?
- can you run this repro in debug mode on show the output when the issue occurs?
- RTT and bandwidth between server and client (race conditions may
depend on specific network performance - not every issue is
reproducible on localhost)
- confirm that FF sandboxing is not affecting this issue by lowering
security.sandbox.content.level to 2 or 0 in about:config (then restart
FF) - don't forget to turn it back on




Thanks,
Lukas



Re: HTTP/2 Termination vs. Firefox Quantum

2017-12-27 Thread Lucas Rolff
I tried enabling “option httplog” within my frontend, I do have the same issue 
wit



Re: haproxy 1.8.2 ALPN h2 broken?

2017-12-27 Thread Lucas Rolff
- you said that using multiple certs breaks, but did you get a working state in 
any way ?

Actually regarding the multiple certs breaking – I was wrong.

So, if I use release 1.8.1 (downloaded from haproxy.org and compiling from 
source) then my bind works perfectly.

If I use release 1.8.2 with same compile options, and I use the same bind, or a 
bind even with a single certificate (  bind *:443 ssl crt 
/etc/haproxy/certs/wildcard_domain.com.pem alpn h2,http/1.1 ) I still end up 
with the same error from curl:

curl: (16) Error in the HTTP2 framing layer

So it’s as long as I pass alpn h2,http/1.1 in my bind “flag” that it breaks.

>  if you run haproxy with -d (debug mode), do you see something like this :

Yes, I see the ALPN=h2:

:https_frontend.accept(0006)=0010 from [80.61.160.xxx:52922] ALPN=h2
:https_frontend.clireq[0010:]: GET / HTTP/1.1
:https_frontend.clihdr[0010:]: user-agent: curl/7.54.1
:https_frontend.clihdr[0010:]: accept: */*
:https_frontend.clihdr[0010:]: host: dashboard.domain.com
:cdn-backend.srvcls[0010:adfd]
:cdn-backend.clicls[0010:adfd]
:cdn-backend.closed[0010:adfd]

> are you sure you didn't limit your buffer size to less than 16kB ?

Config between my compiled 1.8.1 and 1.8.2 didn’t change at all, and I’m also 
not touching buffers within the haproxy config, the only defaults I really set 
is connect, client and server timeouts – the rest pretty much stays the same:

https://gist.github.com/lucasRolff/12b2036baa47400d6c3437a67d9f5fd1 - I try to 
avoid touching things the instance does next to no traffic so defaults *should* 
be fine.
So unless buffers change between 1.8.1 an 1.8.2 then no changes has been done.

The specific request will have a content-length of 55 kilobytes.

> how did you manage to get curl to emit this amount of useful debugging 
> information ? I never got that even after reading all options, I'm jealous!

Use -vvv option in curl – or even better, on http2 enabled sites, you can use 
nghttp -v http://url/ it will give you extensive information regarding your 
http2 traffic – since it will be aware of your streams, priorities etc etc.

Best Regards,
Lucas Rolff

On 27/12/2017, 19.25, "Willy Tarreau"  wrote:

Hi Lucas,

On Wed, Dec 27, 2017 at 04:49:31PM +, Lucas Rolff wrote:
> Hi guys,
> 
> I was running haproxy 1.8.1 and testing out http2, for this I require the 
alpn h2,http/1.1 in my bind - however when using multiple certificates together 
with alpn in 1.8.2 - this seems to break.
> 
> My bind looks like this:
> 
> bind *:443 ssl crt /etc/haproxy/certs/default.pem crt /etc/haproxy/certs 
alpn h2,http/1.1
> 
> So I supply a default certificate (wildcard for a specific domain), 
second I supply a folder that haproxy scans and picks up all certificates 
within that directory - this configuration works perfectly in 1.8.1
> In 1.8.2, I'll get a certificate error whenever I have alpn h2,http/1.1 
added, curl gives following error:
> 
> * Cipher selection: 
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
> * successfully set certificate verify locations:
> *   CAfile: /usr/local/etc/openssl/cert.pem
>   CApath: /usr/local/etc/openssl/certs
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
> * TLSv1.2 (IN), TLS handshake, Server hello (2):
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
> * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
> * TLSv1.2 (IN), TLS change cipher, Client hello (1):
> * TLSv1.2 (IN), TLS handshake, Finished (20):
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
> * ALPN, server accepted to use h2
> * Server certificate:
> *  subject: OU=Domain Control Validated; CN=*.domain.com
> *  start date: Jan  3 11:17:55 2017 GMT
> *  expire date: Jan  4 11:17:55 2018 GMT
> *  subjectAltName: host "dashboard.domain.com" matched cert's 
"*.domain.com"
> *  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
> *  SSL certificate verify ok.
> * Using HTTP2, server supports multi-use
> * Connection state changed (HTTP/2 confirmed)
> * Copying HTTP/2 data in stream buffer to connection buffer after 
upgrade: len=0
> * Using Stream ID: 1 (easy handle 0x7fe99d815400)
> > GET / HTTP/2
> > Host: dashboard.domain.com
> > User-Agent: curl/7.54.1
> > Accept: */*
> >
> * Connection state changed (MAX_CONCURRENT_STREAMS updated)!
> * Closing connection 0
> * TLSv1.2 (OUT), TLS alert, Client hello (1):
> curl: (16) Error in the 

Re: haproxy SSL termination performance

2017-12-27 Thread Willy Tarreau
On Wed, Dec 27, 2017 at 06:06:33PM +, Lucas Rolff wrote:
> Hi Willy,
> 
> I ended up adding an actual backend to perform the test (reused my nginx
> instance I had already), so the connection between haproxy and nginx would be
> a matter of localhost traffic - and I was indeed able to reach about 18k
> req/s on a single core with keep-alive.

It's not keep-alive, it's keep-alive between ab and haproxy but it's close
behind due to "option http-server-close". By removing this option you'll
have keep-alive.

> I can see that reply didn't reach the mailing list however, since I failed to
> see that the mailing list doesn't do an automatic "reply-to:
> haproxy@formilux.org" so have to manually add it,

Ah ? But it's the sender, so you shouldn't have to add it yourself, normally
you should simply perform a group reply and it's OK.

> so it's all solved, and I'm
> happy with the results - on this specific server I was testing from, I did
> reach about 65k req/s on relatively cheap hardware, so even if I want to
> scale to 100k+ req/s it should be no problem from what I can see ( I know
> there will be a slightly bigger overhead when doing a lot of clients also
> because of networking involving more than a single client).

OK that's great.

> So thanks a lot!

You're welcome!

Willy



Re: [PATCH]: spoa example build update

2017-12-27 Thread Willy Tarreau
Thank you. I'll check with Christopher once he's back but I think that
should be OK this way. I may have a suggestion (we'll edit before merging,
don't worry) :

On Wed, Dec 27, 2017 at 06:26:56PM +, David CARLIER wrote:
> From 2e76de286db0e4672a9173e52a070e4b61452983 Mon Sep 17 00:00:00 2001
> From: David Carlier 
> Date: Wed, 27 Dec 2017 13:19:14 +
> Subject: [PATCH] BUILD/SMALL: contrib : spoa example
> 
> Change to the build to be able to build it in systems
> different than Linux.
> ---
>  contrib/spoa_example/Makefile | 8 ++--
>  contrib/spoa_example/spoa.c   | 2 +-
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/contrib/spoa_example/Makefile b/contrib/spoa_example/Makefile
> index c44c2b879..548d280ba 100644
> --- a/contrib/spoa_example/Makefile
> +++ b/contrib/spoa_example/Makefile
> @@ -5,9 +5,13 @@ BINDIR  = $(PREFIX)/bin
>  CC = gcc
>  LD = $(CC)
>  
> +EVENTINC = $(PREFIX)/include
> +EVENTLIB = $(PREFIX)/lib
> +EVENTLIBNM = event
> +
>  CFLAGS  = -g -O2 -Wall -Werror -pthread
> -INCS += -I../../ebtree -I./include
> -LIBS = -lpthread -levent -levent_pthreads
> +INCS += -I../../ebtree -I./include -I$(EVENTINC)
> +LIBS = -lpthread -l$(EVENTLIBNM) -levent_pthreads -L$(EVENTLIB)

Here we could add the -I/-L only if the variable isn't empty, allowing
to use the build system's path only if relevant (very convenient when
cross-compiling as you generally have all your libs in the sysroot but
you never know the sysroot path well) :

  INCS += -I../../ebtree -I./include $(if $(EVENTINC),-I$(EVENTINC))
  LIBS = -lpthread -l$(EVENTLIBNM) -levent_pthreads $(if 
$(EVENTLIB),-L$(EVENTLIB))

I'm just seeing we already have similar ones in the main Makefile for
certain options (SLZ/SLIB/SSL/LUA).

Cheers,
Willy



Re: Article inquiry on Haproxy.Org

2017-12-27 Thread Willy Tarreau
I must confess I love this one. I hope he didn't expect his inquiry to
remain discrete by sending it to the list and being archived forever :-)
Feeding the anti-spam with it now.

Willy

On Wed, Dec 27, 2017 at 06:41:49PM +0800, Daniel Millers wrote:
> Hi team at  Haproxy
> 
> How are you?
> 
> I came across your excellent site: http://haproxy.org
> 
> How much would it be for an article placement with a link in the main
> content area of the article going to a *leading gaming/sports betting
> site*, taking
> into account the 3 points below:
> 
>- We will get the* content written*. The content will be of *high
>quality *and will fit the topic/nature of your site.
>- The article is *not* marked as sponsored and will stay on the site
>*permanently* even if it rolls over into the archives.
>- We will pay you via *Paypal *once the article is live.
> 
> Please update me with a price and will speak to the client ASAP. Also if
> you operate or have access to any other sites, feel free to send them
> through also with prices..
> 
> Thanks so much.
> 
> Regards,
> 
> *Daniel - Account Manager*
> DigitalContentZone



Re: [PATCH]: spoa example build update

2017-12-27 Thread David CARLIER
On 27 December 2017 at 18:18, Willy Tarreau  wrote:

> Hi David,
>
> On Wed, Dec 27, 2017 at 01:23:34PM +, David CARLIER wrote:
> > diff --git a/contrib/spoa_example/Makefile b/contrib/spoa_example/
> Makefile
> > index c44c2b879..71ba6107a 100644
> > --- a/contrib/spoa_example/Makefile
> > +++ b/contrib/spoa_example/Makefile
> > @@ -2,12 +2,14 @@ DESTDIR =
> >  PREFIX  = /usr/local
> >  BINDIR  = $(PREFIX)/bin
> >
> > -CC = gcc
> > +CC ?= gcc
>
> Please don't use "?=". It will inherit stuff from the environment, leading
> to all sort of surprizes. Instead "=" is easily overriden on the command
> line. Example :
>

True. Here a new patch if you like. Cheers.


>
>   $ CC=foo make
>
> will always use "gcc" when the rule says "CC = gcc" but will use "foo" when
> the rule uses "CC ?= gcc".
>
> But :
>
>   $ make CC=foo
>
> will always use "foo" regardless of how you write your rule. If you
> explicitly
> want to force using "$CC" in your case because you do have such a variable
> in
> your environment that you prefer, you can easily do it this way :
>
>   $ make CC=$CC
>
> While it may not seem obvious for a variable such as CC that it's bad to
> have Make automatically inherit random variables, it becomes much more
> visible when you simply type "env" on your shell after a day of work and
> figure the number of things you've added for a temporary usage that you
> forgot to unset and that you'd never want your makefile to automatically
> use! And it's even worse when you make from a script which may sometimes
> set CFLAGS or stuff like this for certain components.
>
> So it's a good practice to isolate makefiles against accidental use of
> environment variables. Some projects have gone to great lengths doing
> this, e.g. to avoid randomly breaking complex build setups (like CFLAGS
> silently being passed through older versions of gcc+glibc+binutils build
> sessions, randomly breaking toolchain utilities, sometimes requiring to
> build several times in a row just to get rid of the issue).
>
> >  CFLAGS  = -g -O2 -Wall -Werror -pthread
> > -INCS += -I../../ebtree -I./include
> > -LIBS = -lpthread -levent -levent_pthreads
> > +INCS += -I../../ebtree -I./include -I$(PREFIX)/include
> > +LIBS = -lpthread -l$(EVENTLIB) -levent_pthreads -L$(PREFIX)/lib
>
> I'm suspecting we may get into new trouble here due to the fact that
> it becomes impossible to remove this one when not relevant. For example
> on some systems you have to use $PREFIX/lib64. On other systems, no
> single $PREFIX will be valid and you risk to get undesired stuff. Also
> when cross-compiling, $PREFIX will point to your native system instead
> of the one in the toolchain.
>
> What exact build problem did you meet in your environment, and with
> what component ? Maybe we can find another way to deal with it. We
> could also imagine setting a set of FOOLIB and FOOINC variables to
> respectively specify the lib and include directories, properly taking
> care of the lib64 crap.
>
> > diff --git a/contrib/spoa_example/spoa.c b/contrib/spoa_example/spoa.c
> > index d8defd192..760ad9210 100644
> > --- a/contrib/spoa_example/spoa.c
> > +++ b/contrib/spoa_example/spoa.c
> > @@ -53,7 +53,7 @@
> >
> \
> >   gettimeofday(, NULL);   \
> >   fprintf(stderr, "%ld.%06ld [%02d] " fmt "\n",   \
> > - now.tv_sec, now.tv_usec, (worker)->id, ##args); \
> > + (long int)now.tv_sec, now.tv_usec, (worker)->id,
> ##args);   \
>
> Good catch!
>
> Cheers,
> Willy
>
From 2e76de286db0e4672a9173e52a070e4b61452983 Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Wed, 27 Dec 2017 13:19:14 +
Subject: [PATCH] BUILD/SMALL: contrib : spoa example

Change to the build to be able to build it in systems
different than Linux.
---
 contrib/spoa_example/Makefile | 8 ++--
 contrib/spoa_example/spoa.c   | 2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/contrib/spoa_example/Makefile b/contrib/spoa_example/Makefile
index c44c2b879..548d280ba 100644
--- a/contrib/spoa_example/Makefile
+++ b/contrib/spoa_example/Makefile
@@ -5,9 +5,13 @@ BINDIR  = $(PREFIX)/bin
 CC = gcc
 LD = $(CC)
 
+EVENTINC = $(PREFIX)/include
+EVENTLIB = $(PREFIX)/lib
+EVENTLIBNM = event
+
 CFLAGS  = -g -O2 -Wall -Werror -pthread
-INCS += -I../../ebtree -I./include
-LIBS = -lpthread -levent -levent_pthreads
+INCS += -I../../ebtree -I./include -I$(EVENTINC)
+LIBS = -lpthread -l$(EVENTLIBNM) -levent_pthreads -L$(EVENTLIB)
 
 OBJS = spoa.o
 
diff --git a/contrib/spoa_example/spoa.c b/contrib/spoa_example/spoa.c
index d8defd192..760ad9210 100644
--- a/contrib/spoa_example/spoa.c
+++ b/contrib/spoa_example/spoa.c
@@ -53,7 +53,7 @@
 \
 		gettimeofday(, NULL);\
 		fprintf(stderr, "%ld.%06ld [%02d] " fmt "\n",		\
-			now.tv_sec, now.tv_usec, (worker)->id, ##args);	\
+			(long 

Re: haproxy 1.8.2 ALPN h2 broken?

2017-12-27 Thread Willy Tarreau
Hi Lucas,

On Wed, Dec 27, 2017 at 04:49:31PM +, Lucas Rolff wrote:
> Hi guys,
> 
> I was running haproxy 1.8.1 and testing out http2, for this I require the 
> alpn h2,http/1.1 in my bind - however when using multiple certificates 
> together with alpn in 1.8.2 - this seems to break.
> 
> My bind looks like this:
> 
> bind *:443 ssl crt /etc/haproxy/certs/default.pem crt /etc/haproxy/certs alpn 
> h2,http/1.1
> 
> So I supply a default certificate (wildcard for a specific domain), second I 
> supply a folder that haproxy scans and picks up all certificates within that 
> directory - this configuration works perfectly in 1.8.1
> In 1.8.2, I'll get a certificate error whenever I have alpn h2,http/1.1 
> added, curl gives following error:
> 
> * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
> * successfully set certificate verify locations:
> *   CAfile: /usr/local/etc/openssl/cert.pem
>   CApath: /usr/local/etc/openssl/certs
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
> * TLSv1.2 (IN), TLS handshake, Server hello (2):
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
> * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
> * TLSv1.2 (IN), TLS change cipher, Client hello (1):
> * TLSv1.2 (IN), TLS handshake, Finished (20):
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
> * ALPN, server accepted to use h2
> * Server certificate:
> *  subject: OU=Domain Control Validated; CN=*.domain.com
> *  start date: Jan  3 11:17:55 2017 GMT
> *  expire date: Jan  4 11:17:55 2018 GMT
> *  subjectAltName: host "dashboard.domain.com" matched cert's "*.domain.com"
> *  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
> *  SSL certificate verify ok.
> * Using HTTP2, server supports multi-use
> * Connection state changed (HTTP/2 confirmed)
> * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: 
> len=0
> * Using Stream ID: 1 (easy handle 0x7fe99d815400)
> > GET / HTTP/2
> > Host: dashboard.domain.com
> > User-Agent: curl/7.54.1
> > Accept: */*
> >
> * Connection state changed (MAX_CONCURRENT_STREAMS updated)!
> * Closing connection 0
> * TLSv1.2 (OUT), TLS alert, Client hello (1):
> curl: (16) Error in the HTTP2 framing layer
> 
> Removing alpn (and http2 support) "fixes" the issue.

Wow that's scary. I have no idea what can cause this at the moment. These
parts are so much isolated that I really don't understand. Just a few
questions :
  - you said that using multiple certs breaks, but did you get a working
state in any way ?

  - if you run haproxy with -d (debug mode), do you see something like
this :

:decrypt.accept(0007)=000b from [127.0.0.1:46158] ALPN=h2
:decrypt.clireq[000b:]: GET / HTTP/1.1
:decrypt.clihdr[000b:]: user-agent: curl/7.54.1
:decrypt.clihdr[000b:]: accept: */*
:decrypt.clihdr[000b:]: host: 127.0.0.1:4443

(note the "ALPN=h2" at the top)

  - are you sure you didn't limit your buffer size to less than 16kB ? I
was supposed to add a parse error for this when parsing a config, and
for a reason I don't remember, I think I didn't add it.

  - how did you manage to get curl to emit this amount of useful debugging
information ? I never got that even after reading all options, I'm jealous!

Thanks,
Willy



Re: haproxy 1.8.2 ALPN h2 broken?

2017-12-27 Thread Olivier Doucet
2017-12-27 19:16 GMT+01:00 Lucas Rolff :

> 1.8.2 is the latest version, or do you mean latest version as in compiling
> master from git?
>

Both are OK to test with.


>
>
> Current build config (my 1.8.1 build config is exactly the same, except
> version number is different):
>
>
>
> HA-Proxy version 1.8.2-08396fa 2017/12/23
>
> Copyright 2000-2017 Willy Tarreau 
>
>
>
> Build options :
>
>   TARGET  = linux2628
>
>   CPU = generic
>
>   CC  = gcc
>
>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> -fwrapv -Wno-unused-label
>
>   OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_PCRE=1
> USE_PCRE_JIT=1
>
>
>
> Default settings :
>
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
>
>
> Built with OpenSSL version : OpenSSL 1.0.2k-fips  26 Jan 2017
>
> Running on OpenSSL version : OpenSSL 1.0.2k-fips  26 Jan 2017
>
> OpenSSL library supports TLS extensions : yes
>
> OpenSSL library supports SNI : yes
>
> OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
>
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
>
> Encrypted password support via crypt(3): yes
>
> Built with multi-threading support.
>
> Built with PCRE version : 8.32 2012-11-30
>
> Running on PCRE version : 8.32 2012-11-30
>
> PCRE library supports JIT : yes
>
> Built with zlib version : 1.2.7
>
> Running on zlib version : 1.2.7
>
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
>
> Built with network namespace support.
>
>
>
> Available polling systems :
>
>   epoll : pref=300,  test result OK
>
>poll : pref=200,  test result OK
>
>  select : pref=150,  test result OK
>
> Total: 3 (3 usable), will use epoll.
>
>
>
> Available filters :
>
>   [SPOE] spoe
>
>   [COMP] compression
>
>   [TRACE] trace
>


And do you have the same issue with this version ?

Olivier



>
>
>
>
>
>
> Hi Lucas,
>
>
>
> There has been so many bugs fixed in HAProxy 1.8.2 you should really check
> this latest version first, and see if you still have this issue.
>
>
>
> Olivier
>
>
>
>
>
>
>
>
>
> 2017-12-27 17:49 GMT+01:00 Lucas Rolff :
>
> Hi guys,
>
>
>
> I was running haproxy 1.8.1 and testing out http2, for this I require the 
> *alpn
> h2,http/1.1 *in my bind – however when using multiple certificates
> together with alpn in 1.8.2 – this seems to break.
>
>
>
> My bind looks like this:
>
>
>
> bind *:443 ssl crt /etc/haproxy/certs/default.pem crt /etc/haproxy/certs
> alpn h2,http/1.1
>
>
>
> So I supply a default certificate (wildcard for a specific domain), second
> I supply a folder that haproxy scans and picks up all certificates within
> that directory – this configuration works perfectly in 1.8.1
>
> In 1.8.2, I’ll get a certificate error whenever I have alpn h2,http/1.1
> added, curl gives following error:
>
>
>
> * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@
> STRENGTH
>
> * successfully set certificate verify locations:
>
> *   CAfile: /usr/local/etc/openssl/cert.pem
>
>   CApath: /usr/local/etc/openssl/certs
>
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
>
> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
>
> * TLSv1.2 (IN), TLS handshake, Server hello (2):
>
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
>
> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
>
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
>
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
>
> * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
>
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
>
> * TLSv1.2 (IN), TLS change cipher, Client hello (1):
>
> * TLSv1.2 (IN), TLS handshake, Finished (20):
>
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
>
> * ALPN, server accepted to use h2
>
> * Server certificate:
>
> *  subject: OU=Domain Control Validated; CN=*.domain.com
>
> *  start date: Jan  3 11:17:55 2017 GMT
>
> *  expire date: Jan  4 11:17:55 2018 GMT
>
> *  subjectAltName: host "dashboard.domain.com" matched cert's "*.
> domain.com"
>
> *  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
>
> *  SSL certificate verify ok.
>
> * Using HTTP2, server supports multi-use
>
> * Connection state changed (HTTP/2 confirmed)
>
> * Copying HTTP/2 data in stream buffer to connection buffer after upgrade:
> len=0
>
> * Using Stream ID: 1 (easy handle 0x7fe99d815400)
>
> > GET / HTTP/2
>
> > Host: dashboard.domain.com
>
> > User-Agent: curl/7.54.1
>
> > Accept: */*
>
> >
>
> * Connection state changed (MAX_CONCURRENT_STREAMS updated)!
>
> * Closing connection 0
>
> * TLSv1.2 (OUT), TLS alert, Client hello (1):
>
> *curl: (16) Error in the HTTP2 framing layer*
>
>
>
> Removing alpn (and http2 support) “fixes” the issue.
>
>
>
> Best Regards,
>
> Lucas Rolff
>
>
>


Re: [PATCH]: spoa example build update

2017-12-27 Thread Willy Tarreau
Hi David,

On Wed, Dec 27, 2017 at 01:23:34PM +, David CARLIER wrote:
> diff --git a/contrib/spoa_example/Makefile b/contrib/spoa_example/Makefile
> index c44c2b879..71ba6107a 100644
> --- a/contrib/spoa_example/Makefile
> +++ b/contrib/spoa_example/Makefile
> @@ -2,12 +2,14 @@ DESTDIR =
>  PREFIX  = /usr/local
>  BINDIR  = $(PREFIX)/bin
>  
> -CC = gcc
> +CC ?= gcc

Please don't use "?=". It will inherit stuff from the environment, leading
to all sort of surprizes. Instead "=" is easily overriden on the command
line. Example :

  $ CC=foo make

will always use "gcc" when the rule says "CC = gcc" but will use "foo" when
the rule uses "CC ?= gcc".

But :

  $ make CC=foo

will always use "foo" regardless of how you write your rule. If you explicitly
want to force using "$CC" in your case because you do have such a variable in
your environment that you prefer, you can easily do it this way :

  $ make CC=$CC

While it may not seem obvious for a variable such as CC that it's bad to
have Make automatically inherit random variables, it becomes much more
visible when you simply type "env" on your shell after a day of work and
figure the number of things you've added for a temporary usage that you
forgot to unset and that you'd never want your makefile to automatically
use! And it's even worse when you make from a script which may sometimes
set CFLAGS or stuff like this for certain components.  

So it's a good practice to isolate makefiles against accidental use of
environment variables. Some projects have gone to great lengths doing
this, e.g. to avoid randomly breaking complex build setups (like CFLAGS
silently being passed through older versions of gcc+glibc+binutils build
sessions, randomly breaking toolchain utilities, sometimes requiring to
build several times in a row just to get rid of the issue).

>  CFLAGS  = -g -O2 -Wall -Werror -pthread
> -INCS += -I../../ebtree -I./include
> -LIBS = -lpthread -levent -levent_pthreads
> +INCS += -I../../ebtree -I./include -I$(PREFIX)/include
> +LIBS = -lpthread -l$(EVENTLIB) -levent_pthreads -L$(PREFIX)/lib

I'm suspecting we may get into new trouble here due to the fact that
it becomes impossible to remove this one when not relevant. For example
on some systems you have to use $PREFIX/lib64. On other systems, no
single $PREFIX will be valid and you risk to get undesired stuff. Also
when cross-compiling, $PREFIX will point to your native system instead
of the one in the toolchain.

What exact build problem did you meet in your environment, and with
what component ? Maybe we can find another way to deal with it. We
could also imagine setting a set of FOOLIB and FOOINC variables to
respectively specify the lib and include directories, properly taking
care of the lib64 crap.

> diff --git a/contrib/spoa_example/spoa.c b/contrib/spoa_example/spoa.c
> index d8defd192..760ad9210 100644
> --- a/contrib/spoa_example/spoa.c
> +++ b/contrib/spoa_example/spoa.c
> @@ -53,7 +53,7 @@
>  \
>   gettimeofday(, NULL);   \
>   fprintf(stderr, "%ld.%06ld [%02d] " fmt "\n",   \
> - now.tv_sec, now.tv_usec, (worker)->id, ##args); \
> + (long int)now.tv_sec, now.tv_usec, (worker)->id, 
> ##args);   \

Good catch!

Cheers,
Willy



Re: haproxy 1.8.2 ALPN h2 broken?

2017-12-27 Thread Lucas Rolff
1.8.2 is the latest version, or do you mean latest version as in compiling 
master from git?

Current build config (my 1.8.1 build config is exactly the same, except version 
number is different):

HA-Proxy version 1.8.2-08396fa 2017/12/23
Copyright 2000-2017 Willy Tarreau >

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv 
-Wno-unused-label
  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.0.2k-fips  26 Jan 2017
Running on OpenSSL version : OpenSSL 1.0.2k-fips  26 Jan 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : yes
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
  [SPOE] spoe
  [COMP] compression
  [TRACE] trace

Best Regards,
Lucas Rolff

From: Olivier Doucet 
Date: Wednesday, 27 December 2017 at 19.14
To: Lucas Rolff 
Cc: "haproxy@formilux.org" 
Subject: Re: haproxy 1.8.2 ALPN h2 broken?

Hi Lucas,

There has been so many bugs fixed in HAProxy 1.8.2 you should really check this 
latest version first, and see if you still have this issue.

Olivier




2017-12-27 17:49 GMT+01:00 Lucas Rolff 
>:
Hi guys,

I was running haproxy 1.8.1 and testing out http2, for this I require the alpn 
h2,http/1.1 in my bind – however when using multiple certificates together with 
alpn in 1.8.2 – this seems to break.

My bind looks like this:

bind *:443 ssl crt /etc/haproxy/certs/default.pem crt /etc/haproxy/certs alpn 
h2,http/1.1

So I supply a default certificate (wildcard for a specific domain), second I 
supply a folder that haproxy scans and picks up all certificates within that 
directory – this configuration works perfectly in 1.8.1
In 1.8.2, I’ll get a certificate error whenever I have alpn h2,http/1.1 added, 
curl gives following error:

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/etc/openssl/cert.pem
  CApath: /usr/local/etc/openssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; CN=*.domain.com
*  start date: Jan  3 11:17:55 2017 GMT
*  expire date: Jan  4 11:17:55 2018 GMT
*  subjectAltName: host "dashboard.domain.com" 
matched cert's "*.domain.com"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fe99d815400)
> GET / HTTP/2
> Host: dashboard.domain.com
> User-Agent: curl/7.54.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (16) Error in the HTTP2 framing layer

Removing alpn (and http2 support) “fixes” the issue.

Best Regards,
Lucas Rolff



Re: haproxy 1.8.2 ALPN h2 broken?

2017-12-27 Thread Olivier Doucet
Hi Lucas,

There has been so many bugs fixed in HAProxy 1.8.2 you should really check
this latest version first, and see if you still have this issue.

Olivier




2017-12-27 17:49 GMT+01:00 Lucas Rolff :

> Hi guys,
>
>
>
> I was running haproxy 1.8.1 and testing out http2, for this I require the 
> *alpn
> h2,http/1.1 *in my bind – however when using multiple certificates
> together with alpn in 1.8.2 – this seems to break.
>
>
>
> My bind looks like this:
>
>
>
> bind *:443 ssl crt /etc/haproxy/certs/default.pem crt /etc/haproxy/certs
> alpn h2,http/1.1
>
>
>
> So I supply a default certificate (wildcard for a specific domain), second
> I supply a folder that haproxy scans and picks up all certificates within
> that directory – this configuration works perfectly in 1.8.1
>
> In 1.8.2, I’ll get a certificate error whenever I have alpn h2,http/1.1
> added, curl gives following error:
>
>
>
> * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@
> STRENGTH
>
> * successfully set certificate verify locations:
>
> *   CAfile: /usr/local/etc/openssl/cert.pem
>
>   CApath: /usr/local/etc/openssl/certs
>
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
>
> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
>
> * TLSv1.2 (IN), TLS handshake, Server hello (2):
>
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
>
> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
>
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
>
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
>
> * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
>
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
>
> * TLSv1.2 (IN), TLS change cipher, Client hello (1):
>
> * TLSv1.2 (IN), TLS handshake, Finished (20):
>
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
>
> * ALPN, server accepted to use h2
>
> * Server certificate:
>
> *  subject: OU=Domain Control Validated; CN=*.domain.com
>
> *  start date: Jan  3 11:17:55 2017 GMT
>
> *  expire date: Jan  4 11:17:55 2018 GMT
>
> *  subjectAltName: host "dashboard.domain.com" matched cert's "*.
> domain.com"
>
> *  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
>
> *  SSL certificate verify ok.
>
> * Using HTTP2, server supports multi-use
>
> * Connection state changed (HTTP/2 confirmed)
>
> * Copying HTTP/2 data in stream buffer to connection buffer after upgrade:
> len=0
>
> * Using Stream ID: 1 (easy handle 0x7fe99d815400)
>
> > GET / HTTP/2
>
> > Host: dashboard.domain.com
>
> > User-Agent: curl/7.54.1
>
> > Accept: */*
>
> >
>
> * Connection state changed (MAX_CONCURRENT_STREAMS updated)!
>
> * Closing connection 0
>
> * TLSv1.2 (OUT), TLS alert, Client hello (1):
>
> *curl: (16) Error in the HTTP2 framing layer*
>
>
>
> Removing alpn (and http2 support) “fixes” the issue.
>
>
>
> Best Regards,
>
> Lucas Rolff
>


Re: haproxy SSL termination performance

2017-12-27 Thread Lucas Rolff
Hi Willy,

I ended up adding an actual backend to perform the test (reused my nginx 
instance I had already), so the connection between haproxy and nginx would be a 
matter of localhost traffic – and I was indeed able to reach about 18k req/s on 
a single core with keep-alive.

I can see that reply didn’t reach the mailing list however, since I failed to 
see that the mailing list doesn’t do an automatic “reply-to: 
haproxy@formilux.org” so have to manually add it, so it’s all solved, and I’m 
happy with the results – on this specific server I was testing from, I did 
reach about 65k req/s on relatively cheap hardware, so even if I want to scale 
to 100k+ req/s it should be no problem from what I can see ( I know there will 
be a slightly bigger overhead when doing a lot of clients also because of 
networking involving more than a single client).

So thanks a lot!

Best Regards,
Lucas Rolff

On 27/12/2017, 19.01, "Willy Tarreau"  wrote:

On Tue, Dec 26, 2017 at 10:28:57AM +0100, Jérôme Magnin wrote:
> 748 looks like what a single core on a VM can achieve in terms of private 
key
> computation with rsa 2048 certs. You can confirm this by running the 
following
> command in your vm:
> 
> openssl speed rsa2048.
> 
> 21000 is too high to be key computation only. 

Indeed, clearly one is doing RSA only while the other one does resume.

> > My haproxy config looks like this: 
https://gist.github.com/lucasRolff/36fc84ac44aad559c1d43ab6f30237c8
> 
> This configuration has no backend, so each request will be replied to 
with a 503
> response containing a connection: close header, which means each request 
will
> lead to a key computation. 

Good catch, indeed the error (even if it's rewritten as a fake 200) will
result in the connection being aborted and I guess then the SSL context
is not kept in ab in this case. Lucas, a better solution is to use a
redirect, such as :

 redirect location /foo

This will not cost much and will perform a complete HTTP rules evaluation
as well. Some of the numbers we've observed here on a single core/single
threaded core i7-4790 :

 1350 TLSv1.2 key computations/s (RSA2048)
14000 TLSv1.2 connection resumes/s
   18 req/s over TLSv1.2 (keep-alive)

By using the redirect above instead of the errorfile, you should be able
to test all these.

Willy




Re: [PATCH] DOC/MINOR: configuration: typo, formatting fixes

2017-12-27 Thread Willy Tarreau
Hi Davor!

On Tue, Dec 26, 2017 at 10:18:34PM +0100, Davor Ocelic wrote:
> From e2dcd863484826a6c38509d78845cb1a88b9f5ab Mon Sep 17 00:00:00 2001
> From: Davor Ocelic 
> Date: Mon, 25 Dec 2017 17:49:28 +0100
 
Got bored eating chocolates under the xmas tree and wanted to read some
doc instead ? :-)

Thanks a lot for this new one. Merged and backported to 1.8.

Willy



Re: haproxy SSL termination performance

2017-12-27 Thread Willy Tarreau
On Tue, Dec 26, 2017 at 10:28:57AM +0100, Jérôme Magnin wrote:
> 748 looks like what a single core on a VM can achieve in terms of private key
> computation with rsa 2048 certs. You can confirm this by running the following
> command in your vm:
> 
> openssl speed rsa2048.
> 
> 21000 is too high to be key computation only. 

Indeed, clearly one is doing RSA only while the other one does resume.

> > My haproxy config looks like this: 
> > https://gist.github.com/lucasRolff/36fc84ac44aad559c1d43ab6f30237c8
> 
> This configuration has no backend, so each request will be replied to with a 
> 503
> response containing a connection: close header, which means each request will
> lead to a key computation. 

Good catch, indeed the error (even if it's rewritten as a fake 200) will
result in the connection being aborted and I guess then the SSL context
is not kept in ab in this case. Lucas, a better solution is to use a
redirect, such as :

 redirect location /foo

This will not cost much and will perform a complete HTTP rules evaluation
as well. Some of the numbers we've observed here on a single core/single
threaded core i7-4790 :

 1350 TLSv1.2 key computations/s (RSA2048)
14000 TLSv1.2 connection resumes/s
   18 req/s over TLSv1.2 (keep-alive)

By using the redirect above instead of the errorfile, you should be able
to test all these.

Willy



haproxy 1.8.2 ALPN h2 broken?

2017-12-27 Thread Lucas Rolff
Hi guys,

I was running haproxy 1.8.1 and testing out http2, for this I require the alpn 
h2,http/1.1 in my bind – however when using multiple certificates together with 
alpn in 1.8.2 – this seems to break.

My bind looks like this:

bind *:443 ssl crt /etc/haproxy/certs/default.pem crt /etc/haproxy/certs alpn 
h2,http/1.1

So I supply a default certificate (wildcard for a specific domain), second I 
supply a folder that haproxy scans and picks up all certificates within that 
directory – this configuration works perfectly in 1.8.1
In 1.8.2, I’ll get a certificate error whenever I have alpn h2,http/1.1 added, 
curl gives following error:

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /usr/local/etc/openssl/cert.pem
  CApath: /usr/local/etc/openssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; CN=*.domain.com
*  start date: Jan  3 11:17:55 2017 GMT
*  expire date: Jan  4 11:17:55 2018 GMT
*  subjectAltName: host "dashboard.domain.com" matched cert's "*.domain.com"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fe99d815400)
> GET / HTTP/2
> Host: dashboard.domain.com
> User-Agent: curl/7.54.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (16) Error in the HTTP2 framing layer

Removing alpn (and http2 support) “fixes” the issue.

Best Regards,
Lucas Rolff


[PATCH]: spoa example build update

2017-12-27 Thread David CARLIER
Hi,

Here a little patch proposal to build the example.

Kind regards.

Thanks in advance.
From e9be79654d9b1f7b63e3f13b9f61b5ad4543cdf3 Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Wed, 27 Dec 2017 13:19:14 +
Subject: [PATCH] BUILD/SMALL: contrib : spoa example

Change to the build to be able to build it in systems
different than Linux.
---
 contrib/spoa_example/Makefile | 8 +---
 contrib/spoa_example/spoa.c   | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/contrib/spoa_example/Makefile b/contrib/spoa_example/Makefile
index c44c2b879..71ba6107a 100644
--- a/contrib/spoa_example/Makefile
+++ b/contrib/spoa_example/Makefile
@@ -2,12 +2,14 @@ DESTDIR =
 PREFIX  = /usr/local
 BINDIR  = $(PREFIX)/bin
 
-CC = gcc
+CC ?= gcc
 LD = $(CC)
 
+EVENTLIB ?= event
+
 CFLAGS  = -g -O2 -Wall -Werror -pthread
-INCS += -I../../ebtree -I./include
-LIBS = -lpthread -levent -levent_pthreads
+INCS += -I../../ebtree -I./include -I$(PREFIX)/include
+LIBS = -lpthread -l$(EVENTLIB) -levent_pthreads -L$(PREFIX)/lib
 
 OBJS = spoa.o
 
diff --git a/contrib/spoa_example/spoa.c b/contrib/spoa_example/spoa.c
index d8defd192..760ad9210 100644
--- a/contrib/spoa_example/spoa.c
+++ b/contrib/spoa_example/spoa.c
@@ -53,7 +53,7 @@
 \
 		gettimeofday(, NULL);\
 		fprintf(stderr, "%ld.%06ld [%02d] " fmt "\n",		\
-			now.tv_sec, now.tv_usec, (worker)->id, ##args);	\
+			(long int)now.tv_sec, now.tv_usec, (worker)->id, ##args);	\
 	} while (0)
 
 #define DEBUG(x...)\
-- 
2.15.1



Article inquiry on Haproxy.Org

2017-12-27 Thread Daniel Millers
Hi team at  Haproxy

How are you?

I came across your excellent site: http://haproxy.org

How much would it be for an article placement with a link in the main
content area of the article going to a *leading gaming/sports betting
site*, taking
into account the 3 points below:

   - We will get the* content written*. The content will be of *high
   quality *and will fit the topic/nature of your site.
   - The article is *not* marked as sponsored and will stay on the site
   *permanently* even if it rolls over into the archives.
   - We will pay you via *Paypal *once the article is live.

Please update me with a price and will speak to the client ASAP. Also if
you operate or have access to any other sites, feel free to send them
through also with prices..

Thanks so much.

Regards,

*Daniel - Account Manager*
DigitalContentZone