HAProxy disable retries

[Yiannis Karayiannidis]

Hi all,
I have a strange HA Proxy *(**HAProxy version 1.5.2)* issue. i don't really
understand why.

I'm trying to disable the retries option from my haproxy. Since i've got
many POST requests

I've got in my conf the following two lines in my defaults section

option redispatch
retries 0

contimeout 18
clitimeout 18
srvtimeout 18


but seems that the haproxy is retrying the connection after 18 sec
which is my default timeout:

Dec  7 11:57:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64351
[07/Dec/2015:11:54:21.588] WEB-http-PORT-80 admin-backend/A1
785/0/0/-1/180787 -1 0 -- cD-- 841/169/1/1/0 0/0 "POST /CloseOrCancelBatch
HTTP/1.1"

Dec  7 12:00:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64344
[07/Dec/2015:11:57:20.207] WEB-http-PORT-80 admin-backend/A1
2259/0/0/-1/182271 -1 0 - - cD-- 816/164/0/0/0 0/0 "POST
/CloseOrCancelBatch HTTP/1.1"

Dec  7 12:00:22 haproxy-http1 haproxy[949]: xxx.xxx.xxx.xxx:64352
[07/Dec/2015:12:00:21.468] WEB-http-PORT-80 admin-backend/A1
1104/0/0/24/1128 200 1876 - -  818/164/1/2/0 0/0 "POST
/CloseOrCancelBatch HTTP/1.1"


Could someone explain what am i doing wrong here?

Is there an option to disable retries only for POST requests which is a bad
thing in any case.

Regards
Yiannis

Re: [1.6.1] Utilizing http-reuse

[Willy Tarreau]

On Tue, Dec 08, 2015 at 07:44:45AM +0530, Krishna Kumar (Engineering) wrote:
> Great, will be glad to test and report on the finding. Thanks!

Sorry I forgot to post the patch after committing it. Here it comes.
Regarding the second point, in the end it's not a bug, it's simply
because we don't have connection pools yet, and I forgot that keeping
an orphan backend connection was only possible with connection pools :-)

Willy

commit 58b318c613b6209d6fe3c9ad38cd11f6814bf7ab
Author: Willy Tarreau 
Date:   Mon Dec 7 17:04:59 2015 +0100

BUG/MEDIUM: http: fix http-reuse when frontend and backend differ

Krishna Kumar reported that the following configuration doesn't permit
HTTP reuse between two clients :

frontend private-frontend
mode http
bind :8001
default_backend private-backend

backend private-backend
mode http
http-reuse always
server bck 127.0.0.1:

The reason for this is that in http_end_txn_clean_session() we check the
stream's backend backend's http-reuse option before deciding whether the
backend connection should be moved back to the server's pool or not. But
since we're doing this after the call to http_reset_txn(), the backend is
reset to match the frontend, which doesn't have the option. However it
will work fine in a setup involving a "listen" section.

We just need to keep a pointer to the current backend before calling
http_reset_txn(). The code does that and replaces the few remaining
references to s->be inside the same function so that if any part of
code were to be moved later, this trap doesn't happen again.

This fix must be backported to 1.6.
(cherry picked from commit 858b103631db41c608660210eb37a9e09ee9f086)

diff --git a/src/proto_http.c b/src/proto_http.c
index 1d00071..5fea6c4 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -5120,6 +5120,7 @@ void http_end_txn_clean_session(struct stream *s)
 {
int prev_status = s->txn->status;
struct proxy *fe = strm_fe(s);
+   struct proxy *be = s->be;
struct connection *srv_conn;
struct server *srv;
unsigned int prev_flags = s->txn->flags;
@@ -5142,7 +5143,7 @@ void http_end_txn_clean_session(struct stream *s)
}
 
if (s->flags & SF_BE_ASSIGNED) {
-   s->be->beconn--;
+   be->beconn--;
if (unlikely(s->srv_conn))
sess_change_server(s, NULL);
}
@@ -5163,11 +5164,11 @@ void http_end_txn_clean_session(struct stream *s)
fe->fe_counters.p.http.comp_rsp++;
}
if ((s->flags & SF_BE_ASSIGNED) &&
-   (s->be->mode == PR_MODE_HTTP)) {
-   s->be->be_counters.p.http.rsp[n]++;
-   s->be->be_counters.p.http.cum_req++;
+   (be->mode == PR_MODE_HTTP)) {
+   be->be_counters.p.http.rsp[n]++;
+   be->be_counters.p.http.cum_req++;
if (s->comp_algo && (s->flags & SF_COMP_READY))
-   s->be->be_counters.p.http.comp_rsp++;
+   be->be_counters.p.http.comp_rsp++;
}
}
 
@@ -5207,7 +5208,7 @@ void http_end_txn_clean_session(struct stream *s)
s->flags &= ~SF_CURR_SESS;
objt_server(s->target)->cur_sess--;
}
-   if (may_dequeue_tasks(objt_server(s->target), s->be))
+   if (may_dequeue_tasks(objt_server(s->target), be))
process_srv_queue(objt_server(s->target));
}
 
@@ -5286,7 +5287,7 @@ void http_end_txn_clean_session(struct stream *s)
if (!srv)
si_idle_conn(>si[1], NULL);
else if ((srv_conn->flags & CO_FL_PRIVATE) ||
-((s->be->options & PR_O_REUSE_MASK) == 
PR_O_REUSE_NEVR))
+((be->options & PR_O_REUSE_MASK) == PR_O_REUSE_NEVR))
si_idle_conn(>si[1], >priv_conns);
else if (prev_flags & TX_NOT_FIRST)
/* note: we check the request, not the connection, but

Re: what's the difference between rspdel and http-response del-header

[Willy Tarreau]

On Tue, Dec 08, 2015 at 11:59:29AM +0800, Ruoshan Huang wrote:
> 
> > On Dec 8, 2015, at 3:26 AM, Willy Tarreau  wrote:
> > 
> > Would you be willing to propose your first patch to address
> > this ? reqadd, reqdel, reqdeny, reqallow, rspadd, rspdel, rspdeny, rspallow
> > are directly concerned.
> 
> 
> Yes, I???d love to update the doc.
> 
> There is one problem here:
> the `reqdel reqidel` works with regular exp, but `http-response del-header`
> only works with plain text. so those old directives are not as
> ???deprecated??? as they are :)

That's true but in practice we almost never need them. The only case is
when you want to remove headers which you don't precisely know the name,
for example all private headers starting with a known prefix. I don't
know if another word is better than "deprecated". Maybe "not recommended
for new designs" ?

> Also, the `rspadd rspdel` runs after `http-response` so things like below
> would not works as expected:
> ```
> rspadd XX:\ default
> http-response set-header XX other if COND
> ```
> the `XX: default` hdr will always in response, can I have this behaviour
> stated in the doc too?

Sure, I'm sorry if I made it sound like it could easily be replaced that
easily, that's not what I meant. My point really was to discourage users
from using these keywords in newer configs. I know there's no 1-to-1
mapping. Feel free to add examples for each keyword if you want! The doc
first appears quite complete, until you need it and discover that there
are not that many examples. So it's a collaborative effort to make it
as clear as possible. Any input is welcome.

Thanks!
Willy

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

I’ve replicated the core dump. I’m debugging it now. Don’t worry about sending 
the certs.

-Dave

From: Bryan Talbot >
Date: Saturday, December 5, 2015 at 7:16 PM
To: Bryan Talbot >
Cc: Yanbo Zhu >, 
"haproxy@formilux.org" 
>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

On Fri, Dec 4, 2015 at 10:17 AM, Bryan Talbot 
> wrote:
On Fri, Dec 4, 2015 at 6:15 AM, Dave Zhu (yanbzhu) 
> wrote:
Hey Bryan,
it’s strange that it’s always loading the ECC cert. I just tested the code on 
my end and I’m not seeing this behavior.


I see it on OSX, I'll test on Linux today.



On Ubuntu VERSION="14.04.3 LTS, Trusty Tahr" with OpenSSL 1.0.2e compiled from 
source, haproxy is crashing with your patches and a bind line of
  bind :8443 ssl crt ./var/tls/localhost.pem

If I change the bind to be
  bind :8443 ssl crt ./var/tls/
it doesn't crash.

OpenSSL 1.0.2e was built and installed to /usr/local/ssl/ with "./config && 
make && make test && sudo make install"
haproxy 1.6.2 was built from source

make -j 4 TARGET=linux2628 USE_OPENSSL=1 SSL_INC=/usr/local/ssl/include 
SSL_LIB=/usr/local/ssl/lib USE_ZLIB=1 ADDLIB=-ldl all

$> ./haproxy -vv
HA-Proxy version 1.6.2 2015/11/03
Copyright 2000-2015 Willy Tarreau >

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1

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

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2e 3 Dec 2015
Running on OpenSSL version : OpenSSL 1.0.2e 3 Dec 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built without PCRE support (using libc's regex instead)
Built without Lua support
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND

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.



$>  ./haproxy -f ./tls-test-haproxy.cfg -c
*** buffer overflow detected ***: ./haproxy terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f59577da38f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f5957871c9c]
/lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f5957870b60]
/lib/x86_64-linux-gnu/libc.so.6(__stpncpy_chk+0x0)[0x7f595786ffc0]
./haproxy[0x48dc4e]
./haproxy[0x490ec8]
./haproxy[0x493090]
./haproxy[0x4932d1]
./haproxy[0x41e27d]
./haproxy[0x42a680]
./haproxy[0x406676]
./haproxy[0x40490c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f5957788ec5]
./haproxy[0x405963]
=== Memory map: 
0040-006cb000 r-xp  08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008ca000-008cb000 r--p 002ca000 08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008cb000-008dc000 rw-p 002cb000 08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008dc000-008ed000 rw-p  00:00 0
01aee000-01b0f000 rw-p  00:00 0  [heap]
7f5957551000-7f5957567000 r-xp  08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957567000-7f5957766000 ---p 00016000 08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957766000-7f5957767000 rw-p 00015000 08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957767000-7f5957922000 r-xp  08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957922000-7f5957b21000 ---p 001bb000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b21000-7f5957b25000 r--p 001ba000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b25000-7f5957b27000 rw-p 001be000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b27000-7f5957b2c000 rw-p  00:00 0
7f5957b2c000-7f5957b2f000 r-xp  08:01 2138   
/lib/x86_64-linux-gnu/libdl-2.19.so
7f5957b2f000-7f5957d2e000 ---p 3000 08:01 2138   
/lib/x86_64-linux-gnu/libdl-2.19.so
7f5957d2e000-7f5957d2f000 r--p 2000 08:01 

Re: lua authentication

[Thierry FOURNIER]

On Sun, 6 Dec 2015 18:35:35 +0100
joris dedieu  wrote:

> 2015-12-06 3:44 GMT+01:00 Grant Haywood :
> > I found a pretty good starting point
> >
> > https://github.com/morganfainberg/HAProxyKeystoneMiddlware
> >
> > if i do anything with ldap ill post it...
> >
> > - Original Message -
> > From: "Grant Haywood" 
> > To: "thierry fournier" 
> > Cc: "Igor Cicimov" , "HAProxy" 
> > , "Baptiste" 
> > Sent: Saturday, December 5, 2015 6:48:52 PM
> > Subject: Re: lua authentication
> >
> > I see.
> > Still, is there an example of authenticating an Http connection in lua?
> >
> > im fairly certan i can do a JWT implementation
> >
> > and for LDAP, it may still easyer to proxy a simple (non-ldap) message over 
> > a socket, and write a bridge to ldap daemon in something thats not lua. 
> > (use at your own risk/understanding/vetting)
> >
> > kind of like this https://doc.powerdns.com/md/authoritative/backend-pipe/
> > (i know thats not for auth, but same concept)
> >
> > - Original Message -
> > From: "thierry fournier" 
> > To: "Baptiste" 
> > Cc: "Grant Haywood" , "Igor Cicimov" 
> > , "HAProxy" 
> > Sent: Saturday, December 5, 2015 3:36:32 PM
> > Subject: Re: lua authentication
> >
> > Hi,
> >
> > I complement, I would say, that the Lua bindings for the standard
> > Openldap client exists, but unfortunately, the operation is blocking,
> > and doesn't run very well with HAProxy.
> >
> > It seems that a Lua rewrite of the LDAP protocol using standard Lua
> > HAProxy socket is a solution, but this is a big development. Maybe a
> > partial implementation (juste the binding) will be usefull.
> >
> > Thierry
> >
> >
> >
> > On Fri, 4 Dec 2015 08:35:41 +0100
> > Baptiste  wrote:
> >
> >> current Lua implementation already allows asynchronous network sockets.
> >> Now, what you need to do is to code a basic LDAP auth request in Lua
> >> and be able to parse the response.
> >>
> >> Baptiste
> >>
> >>
> >>
> >> On Thu, Dec 3, 2015 at 11:58 PM, Grant Haywood  
> >> wrote:
> >> > Thats exactly what I am wanting to code, I just need an example of how 
> >> > to do auth, like userlist, inside of lua.
> >> >
> >> > - Original Message -
> >> > From: "Igor Cicimov" 
> >> > To: "Grant Haywood" 
> >> > Cc: "HAProxy" 
> >> > Sent: Thursday, December 3, 2015 3:58:28 PM
> >> > Subject: Re: lua authentication
> >> >
> >> >
> >> >
> >> >
> >> > Hi Grant,
> >> >
> >> >
> >> >
> >> > On Fri, Dec 4, 2015 at 7:46 AM, Grant Haywood < gr...@iowntheinter.net > 
> >> > wrote:
> >> >
> >> >
> >> > Hello,
> >> >
> >> > I was wondering if there is a basic example of using lua to do 
> >> > authentication?
> >> >
> >> > I am specificaly interested in constructing 'ldap' and 'jwt' versions of 
> >> > the 'userlist' block
> >> >
> >> > thx in advance for your time
> >> >
> >> >
> >> >
> >> > Excellent question. One feature I would love to see in haproxy is 
> >> > support for ldap authentication. It would be awesome If that could be 
> >> > done via lua.
> 
> IHMO it should be easier to use  SASL.


I don't known the SASL protocol, but I tested on openssl Lua library
and it works nicely with Lua/HAProxy. If the SASL can be easyly
implemented with openssl, it will be a nice way.

Thierry


> Joris
> 
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Igor
> >> >
> >>
> >
> 

Re: [1.6.1] Utilizing http-reuse

[Willy Tarreau]

Hi Krishna,

I found a bug explaining your observations and noticed a second one I have
not yet troubleshooted.

The bug causing your issue is that before moving the idle connection back to
the server's pool, we check the backend's http-reuse mode. But we're doing
this after calling http_reset_txn() which prepares the transaction to accept
a new request and sets the backend to the frontend. So we're in fact checking
the frontend's option. That's why it doesn't work in your case. That's a stupid
bug that I managed to fix.

While testing this I discovered another issue (problably less easy to fix,
I'll see). If the client closes an idle connection while there are still
other connections left, the server connection is not moved back to the
server's idle list and is closed. It's not dramatic, but is a waste of
resources since we could maintain that connection open. I'll see if we can
do something simple regarding this case.

I'll send a patch soon for the first case.

Thanks,
Willy

Re: lua authentication

[Thierry FOURNIER]

On Sat, 05 Dec 2015 20:48:52 -0500 (EST)
Grant Haywood  wrote:

> I see.
> Still, is there an example of authenticating an Http connection in lua?


I don't have this type of example avalaible.


> im fairly certan i can do a JWT implementation


I Agree, all the HTTP communication can be used in Lua, but we must
implement the HTTP protocol client based on the embeded sockets.

The core.http object allow to use the "create" object member to use

   "An optional function to be used instead of socket.tcp when the
communications socket is created."

I supposed (but i do not test) that we can do an http request like
this:

   r, resp_code, resp_headers, resp_status = http_req.request {
  method = "POST",
  url = keystone_auth_url,
  headers = headers,
  source = ltn12.source.string(encoded_body),
  sink = ltn12.sink.table(resp_body),
  create = core.tcp
   }

I take the sample code found here:

   
https://github.com/morganfainberg/HAProxyKeystoneMiddlware/blob/master/ha_proxy_ksa.lua

Thierry

> and for LDAP, it may still easyer to proxy a simple (non-ldap) message over a 
> socket, and write a bridge to ldap daemon in something thats not lua. (use at 
> your own risk/understanding/vetting)
> 
> kind of like this https://doc.powerdns.com/md/authoritative/backend-pipe/
> (i know thats not for auth, but same concept)
> 
> - Original Message -
> From: "thierry fournier" 
> To: "Baptiste" 
> Cc: "Grant Haywood" , "Igor Cicimov" 
> , "HAProxy" 
> Sent: Saturday, December 5, 2015 3:36:32 PM
> Subject: Re: lua authentication
> 
> Hi,
> 
> I complement, I would say, that the Lua bindings for the standard
> Openldap client exists, but unfortunately, the operation is blocking,
> and doesn't run very well with HAProxy.
> 
> It seems that a Lua rewrite of the LDAP protocol using standard Lua
> HAProxy socket is a solution, but this is a big development. Maybe a
> partial implementation (juste the binding) will be usefull.
> 
> Thierry
> 
>  
> 
> On Fri, 4 Dec 2015 08:35:41 +0100
> Baptiste  wrote:
> 
> > current Lua implementation already allows asynchronous network sockets.
> > Now, what you need to do is to code a basic LDAP auth request in Lua
> > and be able to parse the response.
> > 
> > Baptiste
> > 
> > 
> > 
> > On Thu, Dec 3, 2015 at 11:58 PM, Grant Haywood  
> > wrote:
> > > Thats exactly what I am wanting to code, I just need an example of how to 
> > > do auth, like userlist, inside of lua.
> > >
> > > - Original Message -
> > > From: "Igor Cicimov" 
> > > To: "Grant Haywood" 
> > > Cc: "HAProxy" 
> > > Sent: Thursday, December 3, 2015 3:58:28 PM
> > > Subject: Re: lua authentication
> > >
> > >
> > >
> > >
> > > Hi Grant,
> > >
> > >
> > >
> > > On Fri, Dec 4, 2015 at 7:46 AM, Grant Haywood < gr...@iowntheinter.net > 
> > > wrote:
> > >
> > >
> > > Hello,
> > >
> > > I was wondering if there is a basic example of using lua to do 
> > > authentication?
> > >
> > > I am specificaly interested in constructing 'ldap' and 'jwt' versions of 
> > > the 'userlist' block
> > >
> > > thx in advance for your time
> > >
> > >
> > >
> > > Excellent question. One feature I would love to see in haproxy is support 
> > > for ldap authentication. It would be awesome If that could be done via 
> > > lua.
> > >
> > >
> > > Thanks,
> > >
> > > Igor
> > >
> > 

Re: lua authentication

[Thierry FOURNIER]

Hi,

Yes, this is a strating point, but be carefull copying this code
because it cannot run with HAProxy. It embeds these blocking libraries:

   local http_req = require('socket.http')
   local io = require("io")

Thierry


On Sat, 05 Dec 2015 21:44:07 -0500 (EST)
Grant Haywood  wrote:

> I found a pretty good starting point
> 
> https://github.com/morganfainberg/HAProxyKeystoneMiddlware
> 
> if i do anything with ldap ill post it...
> 
> - Original Message -
> From: "Grant Haywood" 
> To: "thierry fournier" 
> Cc: "Igor Cicimov" , "HAProxy" 
> , "Baptiste" 
> Sent: Saturday, December 5, 2015 6:48:52 PM
> Subject: Re: lua authentication
> 
> I see.
> Still, is there an example of authenticating an Http connection in lua?
>  
> im fairly certan i can do a JWT implementation
> 
> and for LDAP, it may still easyer to proxy a simple (non-ldap) message over a 
> socket, and write a bridge to ldap daemon in something thats not lua. (use at 
> your own risk/understanding/vetting)
> 
> kind of like this https://doc.powerdns.com/md/authoritative/backend-pipe/
> (i know thats not for auth, but same concept)
> 
> - Original Message -
> From: "thierry fournier" 
> To: "Baptiste" 
> Cc: "Grant Haywood" , "Igor Cicimov" 
> , "HAProxy" 
> Sent: Saturday, December 5, 2015 3:36:32 PM
> Subject: Re: lua authentication
> 
> Hi,
> 
> I complement, I would say, that the Lua bindings for the standard
> Openldap client exists, but unfortunately, the operation is blocking,
> and doesn't run very well with HAProxy.
> 
> It seems that a Lua rewrite of the LDAP protocol using standard Lua
> HAProxy socket is a solution, but this is a big development. Maybe a
> partial implementation (juste the binding) will be usefull.
> 
> Thierry
> 
>  
> 
> On Fri, 4 Dec 2015 08:35:41 +0100
> Baptiste  wrote:
> 
> > current Lua implementation already allows asynchronous network sockets.
> > Now, what you need to do is to code a basic LDAP auth request in Lua
> > and be able to parse the response.
> > 
> > Baptiste
> > 
> > 
> > 
> > On Thu, Dec 3, 2015 at 11:58 PM, Grant Haywood  
> > wrote:
> > > Thats exactly what I am wanting to code, I just need an example of how to 
> > > do auth, like userlist, inside of lua.
> > >
> > > - Original Message -
> > > From: "Igor Cicimov" 
> > > To: "Grant Haywood" 
> > > Cc: "HAProxy" 
> > > Sent: Thursday, December 3, 2015 3:58:28 PM
> > > Subject: Re: lua authentication
> > >
> > >
> > >
> > >
> > > Hi Grant,
> > >
> > >
> > >
> > > On Fri, Dec 4, 2015 at 7:46 AM, Grant Haywood < gr...@iowntheinter.net > 
> > > wrote:
> > >
> > >
> > > Hello,
> > >
> > > I was wondering if there is a basic example of using lua to do 
> > > authentication?
> > >
> > > I am specificaly interested in constructing 'ldap' and 'jwt' versions of 
> > > the 'userlist' block
> > >
> > > thx in advance for your time
> > >
> > >
> > >
> > > Excellent question. One feature I would love to see in haproxy is support 
> > > for ldap authentication. It would be awesome If that could be done via 
> > > lua.
> > >
> > >
> > > Thanks,
> > >
> > > Igor
> > >
> > 

Re:NAHB International Builders' Show 2016

[Charlotte Kate]

Hello,

 

Sorry to interrupt in between your daily schedules. This is just a quick
follow up regarding the email I sent you last week. (Please see below)

 

I would really appreciate if you can give me a short response (not more than
one line) whether you are interested in the attendees' database or not. If
you already possess the database, we can append any missing information like
email, telephone numbers, company profile etc. to enhance your database and
make it ready for your email, telephonic and mailing campaigns. 

 

Have a great day aheadJ

 

Kind regards,

Charlotte

 

From: Charlotte Kate [mailto:charlotte.k...@databaseset.com] 
Sent: Thursday, December 03, 2015 
To: 
Subject: NAHB International Builders' Show 2016

 

Hello,

 

I see that you are one of the promising exhibitors at NAHB International
Builders' Show JAN 19-21, 2016. I am wondering if you are interested in
acquiring the potential Attendees List for this event which you can leverage
for your pre and post event campaigns.

 

Each record in our database comes with all the relevant information about
the attendee including email, phone and mailing address. Hence you can use
this database for your email, telephonic and mailing campaigns. We provide a
contractual guarantee of 90% on our data accuracy.

 

Being one of the largest data compilers out there in the market, we would be
delighted to provide a viable solution for all your data requirements.

Looking forward to hearing from you.

 

PS: If you think I should be talking to someone else, please forward this
email to the concerned person.

 

Kind regards

Charlotte Kate

Database Marketing Specialist 

 

   To unsubscribe, reply with "leave out" in the
subject line

 

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

Hey Bryan,

Are these test certificates? If so could you send them to me so that I can test 
them on my side?

Thanks!
-Dave

From: Bryan Talbot >
Date: Saturday, December 5, 2015 at 7:16 PM
To: Bryan Talbot >
Cc: Yanbo Zhu >, 
"haproxy@formilux.org" 
>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

On Fri, Dec 4, 2015 at 10:17 AM, Bryan Talbot 
> wrote:
On Fri, Dec 4, 2015 at 6:15 AM, Dave Zhu (yanbzhu) 
> wrote:
Hey Bryan,
it’s strange that it’s always loading the ECC cert. I just tested the code on 
my end and I’m not seeing this behavior.


I see it on OSX, I'll test on Linux today.



On Ubuntu VERSION="14.04.3 LTS, Trusty Tahr" with OpenSSL 1.0.2e compiled from 
source, haproxy is crashing with your patches and a bind line of
  bind :8443 ssl crt ./var/tls/localhost.pem

If I change the bind to be
  bind :8443 ssl crt ./var/tls/
it doesn't crash.

OpenSSL 1.0.2e was built and installed to /usr/local/ssl/ with "./config && 
make && make test && sudo make install"
haproxy 1.6.2 was built from source

make -j 4 TARGET=linux2628 USE_OPENSSL=1 SSL_INC=/usr/local/ssl/include 
SSL_LIB=/usr/local/ssl/lib USE_ZLIB=1 ADDLIB=-ldl all

$> ./haproxy -vv
HA-Proxy version 1.6.2 2015/11/03
Copyright 2000-2015 Willy Tarreau >

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1

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

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2e 3 Dec 2015
Running on OpenSSL version : OpenSSL 1.0.2e 3 Dec 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built without PCRE support (using libc's regex instead)
Built without Lua support
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND

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.



$>  ./haproxy -f ./tls-test-haproxy.cfg -c
*** buffer overflow detected ***: ./haproxy terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f59577da38f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f5957871c9c]
/lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f5957870b60]
/lib/x86_64-linux-gnu/libc.so.6(__stpncpy_chk+0x0)[0x7f595786ffc0]
./haproxy[0x48dc4e]
./haproxy[0x490ec8]
./haproxy[0x493090]
./haproxy[0x4932d1]
./haproxy[0x41e27d]
./haproxy[0x42a680]
./haproxy[0x406676]
./haproxy[0x40490c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f5957788ec5]
./haproxy[0x405963]
=== Memory map: 
0040-006cb000 r-xp  08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008ca000-008cb000 r--p 002ca000 08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008cb000-008dc000 rw-p 002cb000 08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008dc000-008ed000 rw-p  00:00 0
01aee000-01b0f000 rw-p  00:00 0  [heap]
7f5957551000-7f5957567000 r-xp  08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957567000-7f5957766000 ---p 00016000 08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957766000-7f5957767000 rw-p 00015000 08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957767000-7f5957922000 r-xp  08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957922000-7f5957b21000 ---p 001bb000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b21000-7f5957b25000 r--p 001ba000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b25000-7f5957b27000 rw-p 001be000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b27000-7f5957b2c000 rw-p  00:00 0
7f5957b2c000-7f5957b2f000 r-xp  08:01 2138   
/lib/x86_64-linux-gnu/libdl-2.19.so
7f5957b2f000-7f5957d2e000 ---p 3000 08:01 2138   
/lib/x86_64-linux-gnu/libdl-2.19.so

HTTP/2 load balancing

[Dennis Jacobfeuerborn]

Hi,
no I'm not asking about when haproxy will begin to support HTTP/2 but
instead I'm wondering how this is going to work in general. The Google
Cloud Platform for example seem to translate HTTP/2 requests from the
client into HTTP/1.1 requests to the servers. While this of course works
it also appears to negate a lot of the advantages of HTTP/2 like
priorities and multiplexing.
On the other hand if the LB creates a new HTTP/2 connection to the
server for each connections from the client that looks like a lot of
overhead.
So my question is what is the best way to deal with this in principle or
to ask differently what is the strategy high performance load balancers
are going to employ to balance HTTP/2 efficiently?

Regards,
  Dennis

24/48 Hours' Turn PCB production Service for you

[Snow]

  

  

  Hi sir，
  
  Have a nice day!
  
  I'm Snow  (^_-)-☆. From Shenzhen Hemeixin Electronic Co., Ltd(pcb).We supply PCB with high quality and competitive price.Hope to cooperate with you !
  
  Why Buy Printed Circuit Boards From HMX?


Our factor and Customer Support Office is located in Shenzhen of China .With strength to provide excellent "DDU" customer service for each and every order.  Our instant online quoting and our online order tracking system makes it more than easy for our customers to place their order with us!


  
Exceptional customer service 24/7 
Best prices：We may not the cheapest in the market. But you won’t find a better price for the quality we  offer. 
Highest quality： We are certified with  UL、ISO2001 and ISO9001. All our PCBs are produced and inspected under IPC Class II and Class III standard.  
No Minimum Order 
Industry's Best On-Time Shipping Record：We offer flexible lead-time, from 3 days to 4 weeks based on your requirement. 
one Day & Weekend Turns 
  Hope to a partner of your company！ 
  Free samples can be sent on request! (*^_^*)　 


  

Best regards,

Snow
  
  
  
  

Shenzhen Hemeixin Electronic Co., Ltd. Website: http://www.hmxpcb.comPhone: 86-0755-29920122 Fax:  86-0755-29922262Address:South Of 5th Floor, 7 Building, Wanxia Industrial Park, 
Tongfuyu Industrial Area, Shajing St., Baoan Dist. , Shenzhen,China 

**
We don't just build boards,we build relationships!
  
  

  

Re: [SPAM] Visibility on tune.ssl.cachesize

[Olivier Doucet]

2015-12-04 8:19 GMT+01:00 Baptiste :

> Hi Olivier,
>
> It's a LRU cache, so I guess the size isn't really important. It will
> be full after some time.
> What you may want to care is the cache miss value reported by a "show
> stat" CLI command.
>

You meant "show info" ? So these fields :

SslRate: 241
SslRateLimit: 0
MaxSslRate: 480
SslFrontendKeyRate: 91
SslFrontendMaxKeyRate: 233
SslFrontendSessionReuse_pct: 62
SslBackendKeyRate: 0
SslBackendMaxKeyRate: 0
SslCacheLookups: 12395011
SslCacheMisses: 2429965



Olivier

Re: [SPAM] Visibility on tune.ssl.cachesize

[Olivier Doucet]

Hello Cyril,


2015-12-04 9:32 GMT+01:00 Cyril Bonté :

> Hi Olivier,
>
> OT : do you have the hand on the ajeux.com DNS entries ? Can you provide
> a (valid) SPF record so that your mails won't be detected as spam anymore.
> I guess you may have some troubles outside of the mailing list too.
>
> Spam system on this mailing list is using barracudacentral, that
misclassified my website ajeux.com ; should have been fixed a few days ago.
Should be OK now.

Olivier

RE: SSL handshake failure when using "send-proxy" on HTTPS backend

[Lukas Tribus]

> Both listen directives on port 8443 uses SSL.
> With Nginx, listening options must be specified on only one "listen"
> directive for each address:port combination.
>
> So the "listen 10.0.80.1:8443" directive inherit parameters from
> "listen 10.0.80.1:8443 default_server ssl proxy_protocol"

True, but its always a good idea to simplify the configuration when
troubleshooting issues like this. For testing purposes therefor, you
should try with just one server declaration (e.g. what if nginx doesn't
propagate the proxy_protocol directive correctly due to a bug?).

To see if haproxy is behaving correctly tcpdump the failed SSL backend
session and check out how it looks on the wire. Then you will have evidence
whether haproxy or nginx is behaving incorrectly.


btw: you are using unencrypted backend traffic as well, whats the reason
to encrypt some but not all of the backend traffic?



Regards,

Lukas

  

Re: [1.6.1] Utilizing http-reuse

[Krishna Kumar (Engineering)]

Great, will be glad to test and report on the finding. Thanks!

Regards,
- Krishna

On Mon, Dec 7, 2015 at 9:07 PM, Willy Tarreau  wrote:

> Hi Krishna,
>
> I found a bug explaining your observations and noticed a second one I have
> not yet troubleshooted.
>
> The bug causing your issue is that before moving the idle connection back
> to
> the server's pool, we check the backend's http-reuse mode. But we're doing
> this after calling http_reset_txn() which prepares the transaction to
> accept
> a new request and sets the backend to the frontend. So we're in fact
> checking
> the frontend's option. That's why it doesn't work in your case. That's a
> stupid
> bug that I managed to fix.
>
> While testing this I discovered another issue (problably less easy to fix,
> I'll see). If the client closes an idle connection while there are still
> other connections left, the server connection is not moved back to the
> server's idle list and is closed. It's not dramatic, but is a waste of
> resources since we could maintain that connection open. I'll see if we can
> do something simple regarding this case.
>
> I'll send a patch soon for the first case.
>
> Thanks,
> Willy
>
>

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Willy Tarreau]

Hi Dave,

On Mon, Dec 07, 2015 at 06:49:54PM +, Dave Zhu (yanbzhu) wrote:
> Bryan found an interesting bug in the code, which I??ve root caused to an
> optimization bug(?)/eccentricity in gcc 4.8.4.

I'm sorry but this is not acceptable. We're hiding a deeper bug somewhere.
Strncpy() is used at other places in the code (a few I agree) and is used
by *a lot* of programs, it's a basic building block. If it's broken in one
version of gcc, it will quickly be fixed, and/or we may have to deploy
workarounds for other places as well. Instead I guess that strncpy() is
detecting a bug that memcpy() doesn't detect so until we find the real
root cause of all of this with a proof that strncpy() contains the real
bug and why it doesn't affect other places, we must not hide it because
I'm pretty sure it will strike back later. Or at least I'd like to see
a pointer to the corresponding bugzilla entry in gcc's bugtracker. I
could imagine one reason being that the sni_keytype would be packed
(for what reason ?) and that the string pointer would start unaligned
and would cause some of strncpy()'s vector optims to fail. But that
sounds extremely strange. By experience when a program dies from such
a small change, it's a latent memory dereference that gets optimized
differently and which manifests itself via memory manipulation functions.
Note that I'm not defending gcc, you might have seen a number of angry
comments from me against it in the code. I just want to be sure we're
addressing the real issue instead of hiding it.

(...)

I'm seeing a buffer overflow in the code prior to the bug seeing the crash,
though its unlikely to trigger but it's here :

   for (i = 0; i < trash.size; i++) {  
   if (!str[i])
   break;  
   trash.str[i] = tolower(str[i]); 
   }   
   trash.str[i] = 0;   

As you can see, if you don't find a 0 in the trash, it will overwrite the
first character not part of the trash buffer.

(...)

@@ -1808,7 +1808,10 @@ static void ssl_sock_populate_sni_keytypes_hplr(const 
char *str, struct eb_root
if (!node) {
/* CN not found in tree */
s_kt = malloc(sizeof(struct sni_keytype) + i + 1);
-   strncpy((char *)s_kt->name.key, trash.str, i);
+   /* Using memcpy here instead of strncpy.
+* strncpy will cause sig_abrt errors under certain version of 
gcc with -O2
+*/
+   memcpy(s_kt->name.key, trash.str, i);
s_kt->name.key[i] = 0;
s_kt->keytypes = 0;
ebst_insert(sni_keytypes, _kt->name);

It might be useful to display s_kt, s_kt->name.key, sizeof(struct sni_keytype)
and i at this place to understand what upsets gcc/strncpy(). If we have to
switch to memcpy() (which I prefer in general), you can remove the manual
addition of the trailing 0 by adding 1 to the size of the memcpy() since
it's guaranteed to cover the zero.

Thanks,
Willy

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Willy Tarreau]

On Mon, Dec 07, 2015 at 08:04:30PM +, Dave Zhu (yanbzhu) wrote:
> One more thing :)
> 
> Out of curiosity, I changed the code as specified in that bugzilla from:
> 
> strncpy((char *)s_kt->name.key, trash.str, i);
> 
> To
> 
>   node = _kt->name;
> strncpy((char *)node->key, trash.str, i);
> 
> And the code ran without an issue. I believe that this is the issue that
> Bryan first saw, and that there isn¹t some malicious underlying memory
> corruption that¹s happening here.

Yep, thanks for the pointer. So indeed gcc's inline version of strncpy *is*
bogus. strncpy() has no right to guess the destination size.

I suspect that if you just do this it would work (prefix the array with '&'
and use [0] :

   strncpy((char *)_kt->name.key[0], trash.str, i);

Thanks,
Willy

Produce various paper printed hang tag for garment industry in high quality

[wangm]

DearSirandMadam, 
Wearealargeprofessionalfactorybasedon=Chinawithmorethan14yearsmanufactureexperience,
 
ourmainproductsare-paperhangtags,-wovenlabels,-cottonlabel,carelabel-embroiderylabelsorlogo,-printedclotheslabels,-heattransferlabels,silverorreflective=color,-rubberlabels,likesoftPVClabel,orsili=conlogolabel-leatherembossedpatch,-lanyard-plasticsealstringtags,hangtablet.
 Youcanvisitourwebsitewww.doylabel.com,=freesamplescanbeoffereduponrequest, 
wewouldhopetobealabelsuppliersforyo=u,andhelptodevelopuniquelabelsforyouritems,andraisethemar=ketshareasmuchaspossible.Plscontactmetodiscussthedetails,looki=ngforwardtohearingfromyousoon!
  Bestregards BettyDOYLABELANDPRINTINGCO.LTD.

Re: [SPAM] Visibility on tune.ssl.cachesize

[Baptiste]

On Mon, Dec 7, 2015 at 11:55 AM, Olivier Doucet  wrote:
>
>
> 2015-12-04 8:19 GMT+01:00 Baptiste :
>>
>> Hi Olivier,
>>
>> It's a LRU cache, so I guess the size isn't really important. It will
>> be full after some time.
>> What you may want to care is the cache miss value reported by a "show
>> stat" CLI command.
>
>
> You meant "show info" ? So these fields :
>
> SslRate: 241
> SslRateLimit: 0
> MaxSslRate: 480
> SslFrontendKeyRate: 91
> SslFrontendMaxKeyRate: 233
> SslFrontendSessionReuse_pct: 62
> SslBackendKeyRate: 0
> SslBackendMaxKeyRate: 0
> SslCacheLookups: 12395011
> SslCacheMisses: 2429965
>
>
>
> Olivier


Yes, you're right.

Baptiste

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Willy Tarreau]

On Mon, Dec 07, 2015 at 08:48:53PM +, Dave Zhu (yanbzhu) wrote:
> Hey Willy
> 
> On 12/7/15, 3:11 PM, "Willy Tarreau"  wrote:
> >
> >Yep, thanks for the pointer. So indeed gcc's inline version of strncpy
> >*is*
> >bogus. strncpy() has no right to guess the destination size.
> >
> >I suspect that if you just do this it would work (prefix the array with
> >'&'
> >and use [0] :
> >
> >   strncpy((char *)_kt->name.key[0], trash.str, i);
> >
> >Thanks,
> >Willy
> 
> You would be correct in this guess :)
> 
> So what¹s the preference? Should I change it to use this weird version of
> strcpy, or change it to memcpy?

I'd prefer the memcpy() anyway. Please keep your comment and add the
link to gcc's bugzilla so that nobody is tempted to change this later
for any reason, and please mention that it's the inlined version of
strncpy() which refuses to write into a char[0].

You have my full support if you want to add some dirty words there to
express your feelings about the compiler which dies on valid C code...

Thanks,
Willy

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Bryan Talbot]

Glad you were able to get to the bottom of the crash.

With the newest 5 patches, I'm still not seeing the behavior I am
expecting. To make my testing and expectations hopefully more clear, I've
pushed them to github (https://github.com/btalbot/dual-stack-test)  From a
laptop with Vagrant installed, it should be a simple process to provision a
host for testing and run the test script.

What I am expecting is that OpenSSL 0.9.8 client will be able to connect to
an haproxy port that is bound to both ECDSA and RSA certificates. This
doesn't work for me and the connection fails the SSL handshake.

I'm also expecting that a newer OpenSSL which support ECC will connect AND
negotiate and use the 256 bit ECDSA certificate and not the RSA cert. My
tests always show the ECC capable client still getting the RSA certificate.



-Bryan




On Mon, Dec 7, 2015 at 1:44 PM, Willy Tarreau  wrote:

> On Mon, Dec 07, 2015 at 08:48:53PM +, Dave Zhu (yanbzhu) wrote:
> > Hey Willy
> >
> > On 12/7/15, 3:11 PM, "Willy Tarreau"  wrote:
> > >
> > >Yep, thanks for the pointer. So indeed gcc's inline version of strncpy
> > >*is*
> > >bogus. strncpy() has no right to guess the destination size.
> > >
> > >I suspect that if you just do this it would work (prefix the array with
> > >'&'
> > >and use [0] :
> > >
> > >   strncpy((char *)_kt->name.key[0], trash.str, i);
> > >
> > >Thanks,
> > >Willy
> >
> > You would be correct in this guess :)
> >
> > So what零 the preference? Should I change it to use this weird version of
> > strcpy, or change it to memcpy?
>
> I'd prefer the memcpy() anyway. Please keep your comment and add the
> link to gcc's bugzilla so that nobody is tempted to change this later
> for any reason, and please mention that it's the inlined version of
> strncpy() which refuses to write into a char[0].
>
> You have my full support if you want to add some dirty words there to
> express your feelings about the compiler which dies on valid C code...
>
> Thanks,
> Willy
>
>

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

I’ve root caused this, it’s a compiler optimization issue with gcc 4.8.4 on 
Ubuntu. I’m trying to figure out why it’s happening as this pattern isn’t new…

If you build with -O0 it goes away, but that’s not acceptable for a production 
software product.

I’ll post a new set of patches when I find the issue.
-Dave

From: Bryan Talbot >
Date: Saturday, December 5, 2015 at 7:16 PM
To: Bryan Talbot >
Cc: Yanbo Zhu >, 
"haproxy@formilux.org" 
>
Subject: Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

On Fri, Dec 4, 2015 at 10:17 AM, Bryan Talbot 
> wrote:
On Fri, Dec 4, 2015 at 6:15 AM, Dave Zhu (yanbzhu) 
> wrote:
Hey Bryan,
it’s strange that it’s always loading the ECC cert. I just tested the code on 
my end and I’m not seeing this behavior.


I see it on OSX, I'll test on Linux today.



On Ubuntu VERSION="14.04.3 LTS, Trusty Tahr" with OpenSSL 1.0.2e compiled from 
source, haproxy is crashing with your patches and a bind line of
  bind :8443 ssl crt ./var/tls/localhost.pem

If I change the bind to be
  bind :8443 ssl crt ./var/tls/
it doesn't crash.

OpenSSL 1.0.2e was built and installed to /usr/local/ssl/ with "./config && 
make && make test && sudo make install"
haproxy 1.6.2 was built from source

make -j 4 TARGET=linux2628 USE_OPENSSL=1 SSL_INC=/usr/local/ssl/include 
SSL_LIB=/usr/local/ssl/lib USE_ZLIB=1 ADDLIB=-ldl all

$> ./haproxy -vv
HA-Proxy version 1.6.2 2015/11/03
Copyright 2000-2015 Willy Tarreau >

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1

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

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2e 3 Dec 2015
Running on OpenSSL version : OpenSSL 1.0.2e 3 Dec 2015
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built without PCRE support (using libc's regex instead)
Built without Lua support
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND

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.



$>  ./haproxy -f ./tls-test-haproxy.cfg -c
*** buffer overflow detected ***: ./haproxy terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f59577da38f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f5957871c9c]
/lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f5957870b60]
/lib/x86_64-linux-gnu/libc.so.6(__stpncpy_chk+0x0)[0x7f595786ffc0]
./haproxy[0x48dc4e]
./haproxy[0x490ec8]
./haproxy[0x493090]
./haproxy[0x4932d1]
./haproxy[0x41e27d]
./haproxy[0x42a680]
./haproxy[0x406676]
./haproxy[0x40490c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f5957788ec5]
./haproxy[0x405963]
=== Memory map: 
0040-006cb000 r-xp  08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008ca000-008cb000 r--p 002ca000 08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008cb000-008dc000 rw-p 002cb000 08:01 268022 
/home/vagrant/haproxy-1.6.2/haproxy
008dc000-008ed000 rw-p  00:00 0
01aee000-01b0f000 rw-p  00:00 0  [heap]
7f5957551000-7f5957567000 r-xp  08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957567000-7f5957766000 ---p 00016000 08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957766000-7f5957767000 rw-p 00015000 08:01 2286   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f5957767000-7f5957922000 r-xp  08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957922000-7f5957b21000 ---p 001bb000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b21000-7f5957b25000 r--p 001ba000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b25000-7f5957b27000 rw-p 001be000 08:01 2269   
/lib/x86_64-linux-gnu/libc-2.19.so
7f5957b27000-7f5957b2c000 rw-p  00:00 0
7f5957b2c000-7f5957b2f000 r-xp  08:01 2138   

Re: Contribution for HAProxy: Peer Cipher based SSL CTX switching

[Dave Zhu (yanbzhu)]

Bryan found an interesting bug in the code, which I’ve root caused to an
optimization bug(?)/eccentricity in gcc 4.8.4.

Either way, I’ve fixed the error and have attached 2 more patches on top
of the 3 already provided. 0004 fixed the bug, and 0005 cleans up some of
the code.

I’m reposting all 5 here so people don’t have to track them down. Patches
1,2, and 3 are identical to the original.

Please take a look.

-Dave

On 12/3/15, 2:35 PM, "Willy Tarreau"  wrote:

>On Thu, Dec 03, 2015 at 07:24:10PM +, Dave Zhu (yanbzhu) wrote:
>> HAProxy will use the first ³crt² file that it loads as the default
>> cert(represented by bind_conf->default_ctx).
>> 
>> So, if you loaded multiple certs in one operation as your first cert,
>> HAProxy will have to determine WHICH cert is the bind_conf->default_ctx.
>> This operation happens during loading of the config, way before any
>>users
>> can connect.
>
>Ah indeed, I had not thought about that.
>
>> What I¹m saying is that the logic for loading multiple certs might
>> generate multiple SSL_CTX¹s depending on CN/SAN overlap. In that case,
>>it
>> will pick the SSL_CTX that has the highest number of different key types
>> and set it as bind_conf->default_ctx if bind_conf->default_ctx has not
>> been set previously.
>> 
>> Does that make sense?
>
>Yes it does. I just feel that it adds some uncertainty (for the admin)
>regarding the choice and that the risk that the default one changes will
>change as individual certs are expired/renewed/updated/replaced.
>
>Maybe at some point we'll have to make it possible to specify (or to
>document) the selection order so that it's stable in time and easy to
>determine.
>
>By the way this ordering may be required as well for other certs if some
>people decide for example to suddenly make RSA picked before ECDSA (if
>a vulnerability is reported or whatever for example). Then in this case
>we could use the same selection rules.
>
>Thanks for your clear explanation!
>Willy
>



0001-MINOR-ssl-Added-cert_key_and_chain-struct.patch
Description: 0001-MINOR-ssl-Added-cert_key_and_chain-struct.patch


0002-MEDIUM-ssl-Added-support-for-creating-SSL_CTX-with-m.patch
Description: 0002-MEDIUM-ssl-Added-support-for-creating-SSL_CTX-with-m.patch


0003-MINOR-ssl-Added-multi-cert-support-for-crt-list-conf.patch
Description: 0003-MINOR-ssl-Added-multi-cert-support-for-crt-list-conf.patch


0004-BUG-MINOR-ssl-Fixed-code-that-crashed-under-optimiza.patch
Description: 0004-BUG-MINOR-ssl-Fixed-code-that-crashed-under-optimiza.patch


0005-MINOR-ssl-Clean-up-unused-code-fixed-spelling-error.patch
Description: 0005-MINOR-ssl-Clean-up-unused-code-fixed-spelling-error.patch

Re: what's the difference between rspdel and http-response del-header

[Ruoshan Huang]

> On Dec 8, 2015, at 3:26 AM, Willy Tarreau  wrote:
> 
> Would you be willing to propose your first patch to address
> this ? reqadd, reqdel, reqdeny, reqallow, rspadd, rspdel, rspdeny, rspallow
> are directly concerned.


Yes, I’d love to update the doc.

There is one problem here:
the `reqdel reqidel` works with regular exp, but `http-response del-header` 
only works with plain text. so those old directives are not as “deprecated” as 
they are :)

Also, the `rspadd rspdel` runs after `http-response` so things like below would 
not works as expected:
```
rspadd XX:\ default
http-response set-header XX other if COND
```
the `XX: default` hdr will always in response, can I have this behaviour stated 
in the doc too?

--
Good day!
ruoshan