Re: Proxy Protocol in 1.4.x ?

[Benjamin Pineau]

Hi,
As a matter of feedback, I use this patch (on HAProxy 1.4.16, for HTTPS
connexions unwrapped by Stud) in production for almost 4 months, and it
works like a charm.

On 08/07/2011 09:34, Brane F. Gračnar wrote:

On Thursday 07 of July 2011 18:30:10 Sebastien Estienne wrote:

Hello,

I'd like to use stud https://github.com/bumptech/stud with Haproxy for
SSL support.
Stud implement the haproxy proxy protocol, and i'd like to know if
this will be backported to haproxy 1.4 ?


First, thanks for pointing out stud, looks very promising!

I'm using accept-proxy patch with haproxy 1.4.15 in production for two months
without any problems on moderate loaded instance (cca 3k concurrent
connections, 700-800 reqs/sec)...

Patch was written by Cyril Bonte, i'm just providing patch file.

Willy, i've been thinking about extending proxy protocol - it would be very
useful if protocol would allow additional, optional fields like tls_cipher,
tls_client_cert info etc... What is your opinion?

I'm also missing ability in haproxy (some kind of built-in acl) if connection
was accepted from listener with accept-proxy flag set.


Best regards, Brane

Re: Proxy Protocol in 1.4.x ?

[Baptiste]

Hi All,

After scaling up Stud, @exceliance, we (actually, @emeriBr) worked to
make it able to scale out:

More information here:
http://blog.exceliance.fr/2011/11/07/scaling-out-ssl/

Regards


On Wed, Sep 28, 2011 at 4:37 PM, Baptiste bed...@gmail.com wrote:
 On the same subject, an excellent article from Vincent:
 http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html

 Good one mate :)

 cheers


 On Mon, Sep 19, 2011 at 12:00 PM, Baptiste bed...@gmail.com wrote:
 Hi there,

 Finally, we've finished our bench on SSL tools available for HAProxy:
 stud and stunnel.
 Please read the benchmark here:

 http://blog.exceliance.fr/2011/09/16/benchmarking_ssl_performance/

 cheers

Re: Proxy Protocol in 1.4.x ?

[Baptiste]

On the same subject, an excellent article from Vincent:
http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html

Good one mate :)

cheers


On Mon, Sep 19, 2011 at 12:00 PM, Baptiste bed...@gmail.com wrote:
 Hi there,

 Finally, we've finished our bench on SSL tools available for HAProxy:
 stud and stunnel.
 Please read the benchmark here:

 http://blog.exceliance.fr/2011/09/16/benchmarking_ssl_performance/

 cheers

Re: Proxy Protocol in 1.4.x ?

[Baptiste]

Hi there,

Finally, we've finished our bench on SSL tools available for HAProxy:
stud and stunnel.
Please read the benchmark here:

http://blog.exceliance.fr/2011/09/16/benchmarking_ssl_performance/

cheers

Re: Proxy Protocol in 1.4.x ?

[Sebastien Estienne]

New benchmark on this topic with haproxy:
http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html


On Saturday, July 9, 2011, Willy Tarreau w...@1wt.eu wrote:
 Hello Sébastien,

 On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote:
 yes we perfectly understand this, and that is what we like about haproxy.
 But the demand for SSL is growing, it s even mandatory for some use
cases.
 Stud looks really promising and solid and a good match for haproxy as it
was designed to be used with haproxy ( http://devblog.bu.mp/introducing-stud).
 Today we have the choice between:
 - haproxy 1.4 + patched stunnel
 - haproxy 1.5 dev + stud
 - patched haproxy 1.4 + stud

 The last one seems the most stable with the best performance, so as the
demand for SSL is growing, i think it would be a big plus that haproxy 1.4
can work with stud  without being patched.

 I see your point. Well, there is also a fourth solution. At Exceliance, we
 have an haproxy enterprise edition (hapee) packaging which includes a
 patched haproxy 1.4, patched stunnel etc... There's a free version you can
 register for. We decided to install it as some of our supported customers
 for free, just because it made maintenance easier for us, and rendered
 their infrastructure more stable.

 I don t know if it would make sense but maybe stud could be integrated
somehow in haproxy like this:
 Instead of starting stud then haproxy separately, the main haproxy
process could fork some stud-like process (binding 443) as it already forks
haproxy childs for multicore and it would discuss using the proxy protocol
transparentlyfor the end user with no need to setup the link between both.

 It's amusing that you're saying that : when I looked at the code, I
thought
 they use the same design model as haproxy and they have the same goals,
 maybe this could be merged. My goal with SSL in haproxy is that we can
 dedicate threads or processes to that task, thus some core changes are
still
 needed, but a first step might precisely be to have totally independant
 processes communicating over a unix socket pair and the proxy protocol.
 It's just not trivial yet to reach the server in SSL, but one thing at a
 time...

 This would offer a seemless SSL integration without hurting haproxy
codebase and stability for clear http content.

 Exactly.

 Thanks for your insights, they comfort me in that mine were not too
 excentric :-)

 Willy



-- 
Sebastien Estienne

Re: Proxy Protocol in 1.4.x ?

[Baptiste]

Hi Sebastien,

Actually, bumptech has not yet integrated all the patches developed by Emeric.
And the stunnel version used is the one without Exceliance (Emeric
again) patches.

But definitely, stud is interesting.

cheers


On Tue, Aug 23, 2011 at 1:02 PM, Sebastien Estienne
sebastien.estie...@gmail.com wrote:
 New benchmark on this topic with haproxy:
 http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html


 On Saturday, July 9, 2011, Willy Tarreau w...@1wt.eu wrote:
 Hello Sébastien,

 On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote:
 yes we perfectly understand this, and that is what we like about haproxy.
 But the demand for SSL is growing, it s even mandatory for some use
 cases.
 Stud looks really promising and solid and a good match for haproxy as it
 was designed to be used with haproxy ( http://devblog.bu.mp/introducing-stud
 ).
 Today we have the choice between:
 - haproxy 1.4 + patched stunnel
 - haproxy 1.5 dev + stud
 - patched haproxy 1.4 + stud

 The last one seems the most stable with the best performance, so as the
 demand for SSL is growing, i think it would be a big plus that haproxy 1.4
 can work with stud  without being patched.

 I see your point. Well, there is also a fourth solution. At Exceliance, we
 have an haproxy enterprise edition (hapee) packaging which includes a
 patched haproxy 1.4, patched stunnel etc... There's a free version you can
 register for. We decided to install it as some of our supported customers
 for free, just because it made maintenance easier for us, and rendered
 their infrastructure more stable.

 I don t know if it would make sense but maybe stud could be integrated
 somehow in haproxy like this:
 Instead of starting stud then haproxy separately, the main haproxy
 process could fork some stud-like process (binding 443) as it already forks
 haproxy childs for multicore and it would discuss using the proxy protocol
 transparentlyfor the end user with no need to setup the link between both.

 It's amusing that you're saying that : when I looked at the code, I
 thought
 they use the same design model as haproxy and they have the same goals,
 maybe this could be merged. My goal with SSL in haproxy is that we can
 dedicate threads or processes to that task, thus some core changes are
 still
 needed, but a first step might precisely be to have totally independant
 processes communicating over a unix socket pair and the proxy protocol.
 It's just not trivial yet to reach the server in SSL, but one thing at a
 time...

 This would offer a seemless SSL integration without hurting haproxy
 codebase and stability for clear http content.

 Exactly.

 Thanks for your insights, they comfort me in that mine were not too
 excentric :-)

 Willy



 --
 Sebastien Estienne

Re: Proxy Protocol in 1.4.x ?

[Baptiste]

I wish I have enough time :)
All the bench have been run, just need time to write it down!

cheers

On Tue, Aug 23, 2011 at 2:04 PM, Sebastien Estienne
sebastien.estie...@gmail.com wrote:
 could publish some benchmark of haproxy + all best ssl frontend.
 i think it would be really valuable infos for the haproxy community.
 thanx

 --
 Sebastien E.


 Le 23 août 2011 à 13:29, Baptiste bed...@gmail.com a écrit :

 Hi Sebastien,

 Actually, bumptech has not yet integrated all the patches developed by 
 Emeric.
 And the stunnel version used is the one without Exceliance (Emeric
 again) patches.

 But definitely, stud is interesting.

 cheers


 On Tue, Aug 23, 2011 at 1:02 PM, Sebastien Estienne
 sebastien.estie...@gmail.com wrote:
 New benchmark on this topic with haproxy:
 http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html


 On Saturday, July 9, 2011, Willy Tarreau w...@1wt.eu wrote:
 Hello Sébastien,

 On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote:
 yes we perfectly understand this, and that is what we like about haproxy.
 But the demand for SSL is growing, it s even mandatory for some use
 cases.
 Stud looks really promising and solid and a good match for haproxy as it
 was designed to be used with haproxy ( 
 http://devblog.bu.mp/introducing-stud
 ).
 Today we have the choice between:
 - haproxy 1.4 + patched stunnel
 - haproxy 1.5 dev + stud
 - patched haproxy 1.4 + stud

 The last one seems the most stable with the best performance, so as the
 demand for SSL is growing, i think it would be a big plus that haproxy 1.4
 can work with stud  without being patched.

 I see your point. Well, there is also a fourth solution. At Exceliance, we
 have an haproxy enterprise edition (hapee) packaging which includes a
 patched haproxy 1.4, patched stunnel etc... There's a free version you can
 register for. We decided to install it as some of our supported customers
 for free, just because it made maintenance easier for us, and rendered
 their infrastructure more stable.

 I don t know if it would make sense but maybe stud could be integrated
 somehow in haproxy like this:
 Instead of starting stud then haproxy separately, the main haproxy
 process could fork some stud-like process (binding 443) as it already 
 forks
 haproxy childs for multicore and it would discuss using the proxy protocol
 transparentlyfor the end user with no need to setup the link between both.

 It's amusing that you're saying that : when I looked at the code, I
 thought
 they use the same design model as haproxy and they have the same goals,
 maybe this could be merged. My goal with SSL in haproxy is that we can
 dedicate threads or processes to that task, thus some core changes are
 still
 needed, but a first step might precisely be to have totally independant
 processes communicating over a unix socket pair and the proxy protocol.
 It's just not trivial yet to reach the server in SSL, but one thing at a
 time...

 This would offer a seemless SSL integration without hurting haproxy
 codebase and stability for clear http content.

 Exactly.

 Thanks for your insights, they comfort me in that mine were not too
 excentric :-)

 Willy



 --
 Sebastien Estienne

Re: Proxy Protocol in 1.4.x ?

[Brane F. Gračnar]

On Friday 08 of July 2011 23:17:12 Sébastien Estienne wrote:
 http://devblog.bu.mp/introducing-stud ). Today we have the choice between:
 - haproxy 1.4 + patched stunnel
 - haproxy 1.5 dev + stud
 - patched haproxy 1.4 + stud

There is also fourth option:

- patched haproxy 1.4.x + patched stunnel (accept-proxy patch)

I'm using attached patch (found it on internet) with stunnel 4.34.

Best regards, Brane
diff -ru stunnel-4.34/src/client.c stunnel-4.34-exceliance-aloha-sendproxy/src/client.c
--- stunnel-4.34/src/client.c	2010-09-14 17:03:43.0 +0200
+++ stunnel-4.34-exceliance-aloha-sendproxy/src/client.c	2010-12-07 22:46:32.421248698 +0100
@@ -86,6 +86,8 @@
 c-opt=opt;
 c-local_rfd.fd=rfd;
 c-local_wfd.fd=wfd;
+if (c-opt-option.sendproxy)
+c-sendproxy = 1;
 return c;
 }
 
@@ -564,6 +566,73 @@
 }
 }
 
+	if (c-sendproxy  !c-ssl_ptr) {
+		int cfd;
+		struct sockaddr_storage local_addr;
+		struct sockaddr_storage peer_addr;
+		u_char family = AF_UNSPEC;
+
+		cfd = SSL_get_fd(c-ssl);
+		if (cfd != -1) {
+			size_t namelen;
+
+			namelen = sizeof(local_addr);
+			if (!getsockname(cfd, (struct sockaddr *)local_addr, namelen)) {
+namelen = sizeof(peer_addr);
+if (!getpeername(cfd, (struct sockaddr *)peer_addr, namelen))
+	family = peer_addr.ss_family;
+			}
+		}
+
+		if (family == AF_INET) {
+
+			if (BUFFSIZE = 11) {
+memcpy(c-ssl_buff, PROXY TCP4 , 11);
+c-ssl_ptr += 11;
+			}
+
+			if (inet_ntop(peer_addr.ss_family, ((struct sockaddr_in*)peer_addr)-sin_addr, c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr)) {
+c-ssl_ptr += strlen(c-ssl_buff+c-ssl_ptr);
+			}
+			if (c-ssl_ptr != BUFFSIZE) {
+c-ssl_buff[c-ssl_ptr] = ' ';
+c-ssl_ptr++;
+			}
+			if (inet_ntop(local_addr.ss_family, ((struct sockaddr_in*)local_addr)-sin_addr, c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr)) {
+c-ssl_ptr += strlen(c-ssl_buff+c-ssl_ptr);
+			}
+			c-ssl_ptr += snprintf(c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr,  %u %u\r\n, ntohs(((struct sockaddr_in*)peer_addr)-sin_port), ntohs(((struct sockaddr_in*)local_addr)-sin_port));
+		}
+#if defined(USE_IPv6)  !defined(USE_WIN32)			
+		else if (family == AF_INET6) {
+
+			if (BUFFSIZE = 11) {
+memcpy(c-ssl_buff, PROXY TCP6 , 11);
+c-ssl_ptr += 11;
+}
+
+if (inet_ntop(peer_addr.ss_family, ((struct sockaddr_in6*)peer_addr)-sin6_addr, c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr)) {
+c-ssl_ptr += strlen(c-ssl_buff+c-ssl_ptr);
+}
+if (c-ssl_ptr != BUFFSIZE) {
+c-ssl_buff[c-ssl_ptr] = ' ';
+c-ssl_ptr++;
+}
+if (inet_ntop(local_addr.ss_family, ((struct sockaddr_in6*)local_addr)-sin6_addr, c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr)) {
+c-ssl_ptr += strlen(c-ssl_buff+c-ssl_ptr);
+}
+c-ssl_ptr += snprintf(c-ssl_buff+c-ssl_ptr, BUFFSIZE-c-ssl_ptr,  %u %u\r\n, ntohs(((struct sockaddr_in6*)peer_addr)-sin6_port), ntohs(((struct sockaddr_in6*)local_addr)-sin6_port));
+		}
+#endif
+		else {
+			if (BUFFSIZE = 15) {
+memcpy(c-ssl_buff, PROXY UNKNOWN\r\n , 15);
+c-ssl_ptr += 15;
+}
+		}
+		c-sendproxy = 0;
+	}
+
 /** update *_wants_* based on new *_ptr */
 /* this update is also required for SSL_pending() to be used */
 read_wants_read=
diff -ru stunnel-4.34/src/options.c stunnel-4.34-exceliance-aloha-sendproxy/src/options.c
--- stunnel-4.34/src/options.c	2010-09-14 17:09:36.0 +0200
+++ stunnel-4.34-exceliance-aloha-sendproxy/src/options.c	2010-12-07 22:46:26.613204761 +0100
@@ -818,6 +818,29 @@
 }
 #endif
 
+/* sendproxy */
+switch(cmd) {
+case CMD_INIT:
+section-option.sendproxy=0;
+break;
+case CMD_EXEC:
+if(strcasecmp(opt, sendproxy))
+break;
+if(!strcasecmp(arg, yes))
+section-option.sendproxy=1;
+else if(!strcasecmp(arg, no))
+section-option.sendproxy=0;
+else
+return argument should be either 'yes' or 'no';
+return NULL; /* OK */
+case CMD_DEFAULT:
+break;
+case CMD_HELP:
+s_log(LOG_NOTICE, %-15s = yes|no append proxy prefix,
+sendproxy);
+break;
+}
+
 /* exec */
 switch(cmd) {
 case CMD_INIT:
diff -ru stunnel-4.34/src/prototypes.h stunnel-4.34-exceliance-aloha-sendproxy/src/prototypes.h
--- stunnel-4.34/src/prototypes.h	2010-09-14 17:09:50.0 +0200
+++ stunnel-4.34-exceliance-aloha-sendproxy/src/prototypes.h	2010-12-07 22:47:39.633763055 +0100
@@ -176,6 +176,7 @@
 unsigned int retry:1; /* loop remote+program */
 

Re: Proxy Protocol in 1.4.x ?

[Brane F. Gračnar]

On Thursday 07 of July 2011 18:30:10 Sebastien Estienne wrote:
 Hello,
 
 I'd like to use stud https://github.com/bumptech/stud with Haproxy for
 SSL support.
 Stud implement the haproxy proxy protocol, and i'd like to know if
 this will be backported to haproxy 1.4 ?

First, thanks for pointing out stud, looks very promising!

I'm using accept-proxy patch with haproxy 1.4.15 in production for two months 
without any problems on moderate loaded instance (cca 3k concurrent 
connections, 700-800 reqs/sec)...

Patch was written by Cyril Bonte, i'm just providing patch file.

Willy, i've been thinking about extending proxy protocol - it would be very 
useful if protocol would allow additional, optional fields like tls_cipher, 
tls_client_cert info etc... What is your opinion?

I'm also missing ability in haproxy (some kind of built-in acl) if connection 
was accepted from listener with accept-proxy flag set.


Best regards, Brane
diff -ru haproxy-1.4.10/doc/configuration.txt haproxy-1.4.10-accept-proxy/doc/configuration.txt
--- haproxy-1.4.10/doc/configuration.txt	2010-11-29 07:36:47.0 +0100
+++ haproxy-1.4.10-accept-proxy/doc/configuration.txt	2010-12-07 22:31:24.721186953 +0100
@@ -1318,6 +1318,7 @@
 bind [address]:port_range [, ...] id id
 bind [address]:port_range [, ...] name name
 bind [address]:port_range [, ...] defer-accept
+bind [address]:port_range [, ...] accept-proxy
   Define one or several listening addresses and/or ports in a frontend.
   May be used in sections :   defaults | frontend | listen | backend
   no   |yes   |   yes  |   no
@@ -1398,6 +1399,19 @@
   with front firewalls which would see an established
   connection while the proxy will only see it in SYN_RECV.
 
+accept-proxy  is an optional keyword which enforces use of the PROXY
+  protocol over any connection accepted by this listener. The
+  PROXY protocol dictates the layer 3/4 addresses of the
+  incoming connection to be used everywhere an address is used,
+  with the only exception of tcp-request connection rules
+  which will only see the real connection address. Logs will
+  reflect the addresses indicated in the protocol, unless it is
+  violated, in which case the real address will still be used.
+  This keyword combined with support from external components
+  can be used as an efficient and reliable alternative to the
+  X-Forwarded-For mechanism which is not always reliable and
+  not even always usable.
+
   It is possible to specify a list of address:port combinations delimited by
   commas. The frontend will then listen on all of these addresses. There is no
   fixed limit to the number of addresses and ports which can be listened on in
@@ -1408,8 +1422,10 @@
 listen http_proxy
 bind :80,:443
 bind 10.0.0.1:10080,10.0.0.1:10443
+bind 127.0.0.1:8443 accept-proxy
 
-  See also : source.
+  See also : source, option forwardfor and the PROXY protocol
+ documentation.
 
 
 bind-process [ all | odd | even | number 1-32 ] ...
@@ -7116,7 +7132,9 @@
 
 Detailed fields description :
   - client_ip is the IP address of the client which initiated the TCP
-connection to haproxy.
+connection to haproxy. Note that when the connection is accepted on a
+socket configured with accept-proxy and the PROXY protocol is correctly
+used, then the logs will reflect the forwarded connection's information.
 
   - client_port is the TCP port of the client which initiated the connection.
 
@@ -7289,7 +7307,9 @@
 
 Detailed fields description :
   - client_ip is the IP address of the client which initiated the TCP
-connection to haproxy.
+connection to haproxy. Note that when the connection is accepted on a
+socket configured with accept-proxy and the PROXY protocol is correctly
+used, then the logs will reflect the forwarded connection's information.
 
   - client_port is the TCP port of the client which initiated the connection.
 
diff -ru haproxy-1.4.10/include/common/standard.h haproxy-1.4.10-accept-proxy/include/common/standard.h
--- haproxy-1.4.10/include/common/standard.h	2010-11-29 07:36:47.0 +0100
+++ haproxy-1.4.10-accept-proxy/include/common/standard.h	2010-12-07 22:00:46.959888470 +0100
@@ -262,6 +262,28 @@
 	return i;
 }
 
+/* This function reads an unsigned integer from the string pointed to by s
+ * and returns it. The s pointer is adjusted to point to the first unread
+ * char. The function automatically stops at end.
+ */
+static inline unsigned int __read_uint(const char **s, const char *end)
+{
+	const char *ptr = *s;
+	unsigned int i = 0;
+	unsigned int j, k;
+
+	while (ptr  end) {
+		j = *ptr - '0';
+		k = i * 10;
+		if (j  9)
+			break;
+		i = k + j;
+		ptr++;
+	}
+	*s = ptr;
+	

Re: Proxy Protocol in 1.4.x ?

[Willy Tarreau]

Hi Brane,

On Fri, Jul 08, 2011 at 09:34:21AM +0200, Brane F. Gra??nar wrote:
 I'm using accept-proxy patch with haproxy 1.4.15 in production for two months 
 without any problems on moderate loaded instance (cca 3k concurrent 
 connections, 700-800 reqs/sec)...

thanks for your report.

 Patch was written by Cyril Bonte, i'm just providing patch file.
 
 Willy, i've been thinking about extending proxy protocol - it would be very 
 useful if protocol would allow additional, optional fields like tls_cipher, 
 tls_client_cert info etc... What is your opinion?

I think the protocol can be extended, it was designed to do so.
However, we should be careful. Right now it's designed so that
low level client information is sent (I mean layer4). If upper
layer protocol information are to be added, we should ensure to
respect layering so that parsers don't have to read everything
and that they can easily ignore what they don't care about.

 I'm also missing ability in haproxy (some kind of built-in acl) if connection 
 was accepted from listener with accept-proxy flag set.

In fact you can already do this. The ACLs support the so_id match which
matches on the ID of the accepting socket. You can simply force your socket's
ID using the id parameter (in order no to have to guess it) and use that in
your rules :

frontend pub
bind :80
bind 127.0.0.1:81 accept-proxy id 10
...
acl from-proxy so_id 10

Cheers,
Willy

Re: Proxy Protocol in 1.4.x ?

[Sébastien Estienne]

Sebastien Estienne

On 7 juil. 2011, at 20:10, Willy Tarreau w...@1wt.eu wrote:

 Hi Sebastien,
 
 On Thu, Jul 07, 2011 at 06:30:10PM +0200, Sebastien Estienne wrote:
 Hello,
 
 I'd like to use stud https://github.com/bumptech/stud with Haproxy for
 SSL support.
 Stud implement the haproxy proxy protocol, and i'd like to know if
 this will be backported to haproxy 1.4 ?
 
 We have a patch for haproxy 1.4, but at this point I'd rather avoid
 backporting it in mainline, because whatever we add to mainline
 presents a risk of regression and mechanically induces new versions
 for fixes. It's important that we can provide as much as possible
 safe 1.4 versions now, it's deployed at a number of sensible sites
 and we have to be careful. I think that as you can understand if
 you're a 1.4 user right now.
 

yes we perfectly understand this, and that is what we like about haproxy.
But the demand for SSL is growing, it s even mandatory for some use cases.
Stud looks really promising and solid and a good match for haproxy as it was 
designed to be used with haproxy ( http://devblog.bu.mp/introducing-stud ).
Today we have the choice between:
- haproxy 1.4 + patched stunnel
- haproxy 1.5 dev + stud
- patched haproxy 1.4 + stud

The last one seems the most stable with the best performance, so as the demand 
for SSL is growing, i think it would be a big plus that haproxy 1.4 can work 
with stud  without being patched.

I don t know if it would make sense but maybe stud could be integrated somehow 
in haproxy like this:
Instead of starting stud then haproxy separately, the main haproxy process 
could fork some stud-like process (binding 443) as it already forks haproxy 
childs for multicore and it would discuss using the proxy protocol 
transparentlyfor the end user with no need to setup the link between both.

This would offer a seemless SSL integration without hurting haproxy codebase 
and stability for clear http content.


 However, if we notice there is growing demand before 1.5 is released
 and the patch looks totally safe, I'm not opposed to reconsider my
 statement.
 
 Concerning stud, I did not know about it. I think it will be very
 appealing to a number of current stunnel users. It looks like strong
 guys are contributing to it, and the fact that it adopted the PROXY
 protocol could make it easier to integrate than stunnel !
 
 Cheers,
 Willy
 

Re: Proxy Protocol in 1.4.x ?

[Willy Tarreau]

Hello Sébastien,

On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote:
 yes we perfectly understand this, and that is what we like about haproxy.
 But the demand for SSL is growing, it s even mandatory for some use cases.
 Stud looks really promising and solid and a good match for haproxy as it was 
 designed to be used with haproxy ( http://devblog.bu.mp/introducing-stud ).
 Today we have the choice between:
 - haproxy 1.4 + patched stunnel
 - haproxy 1.5 dev + stud
 - patched haproxy 1.4 + stud

 The last one seems the most stable with the best performance, so as the 
 demand for SSL is growing, i think it would be a big plus that haproxy 1.4 
 can work with stud  without being patched.

I see your point. Well, there is also a fourth solution. At Exceliance, we
have an haproxy enterprise edition (hapee) packaging which includes a
patched haproxy 1.4, patched stunnel etc... There's a free version you can
register for. We decided to install it as some of our supported customers
for free, just because it made maintenance easier for us, and rendered
their infrastructure more stable.

 I don t know if it would make sense but maybe stud could be integrated 
 somehow in haproxy like this:
 Instead of starting stud then haproxy separately, the main haproxy process 
 could fork some stud-like process (binding 443) as it already forks haproxy 
 childs for multicore and it would discuss using the proxy protocol 
 transparentlyfor the end user with no need to setup the link between both.

It's amusing that you're saying that : when I looked at the code, I thought
they use the same design model as haproxy and they have the same goals,
maybe this could be merged. My goal with SSL in haproxy is that we can
dedicate threads or processes to that task, thus some core changes are still
needed, but a first step might precisely be to have totally independant
processes communicating over a unix socket pair and the proxy protocol.
It's just not trivial yet to reach the server in SSL, but one thing at a
time...

 This would offer a seemless SSL integration without hurting haproxy codebase 
 and stability for clear http content.

Exactly.

Thanks for your insights, they comfort me in that mine were not too
excentric :-)

Willy

Proxy Protocol in 1.4.x ?

[Sebastien Estienne]

Hello,

I'd like to use stud https://github.com/bumptech/stud with Haproxy for
SSL support.
Stud implement the haproxy proxy protocol, and i'd like to know if
this will be backported to haproxy 1.4 ?

thanx,
Sebastien Estienne

Re: Proxy Protocol in 1.4.x ?

[Willy Tarreau]

Hi Sebastien,

On Thu, Jul 07, 2011 at 06:30:10PM +0200, Sebastien Estienne wrote:
 Hello,
 
 I'd like to use stud https://github.com/bumptech/stud with Haproxy for
 SSL support.
 Stud implement the haproxy proxy protocol, and i'd like to know if
 this will be backported to haproxy 1.4 ?

We have a patch for haproxy 1.4, but at this point I'd rather avoid
backporting it in mainline, because whatever we add to mainline
presents a risk of regression and mechanically induces new versions
for fixes. It's important that we can provide as much as possible
safe 1.4 versions now, it's deployed at a number of sensible sites
and we have to be careful. I think that as you can understand if
you're a 1.4 user right now.

However, if we notice there is growing demand before 1.5 is released
and the patch looks totally safe, I'm not opposed to reconsider my
statement.

Concerning stud, I did not know about it. I think it will be very
appealing to a number of current stunnel users. It looks like strong
guys are contributing to it, and the fact that it adopted the PROXY
protocol could make it easier to integrate than stunnel !

Cheers,
Willy