Re: [PATCH] [RFC]/MINOR: connection: Add server name to proxy protocol v2 header.

[Amos Jeffries]

On 27/05/2016 2:42 a.m., Willy Tarreau wrote:
> On Thu, May 26, 2016 at 10:20:36AM -0400, Erik Seres wrote:
>> Hi Willy,
>>
>> Attached is my updated patch per your styling update request.
> 
> Thanks Erik. I'm now CCing Dave and Amos, both of whom worked on this
> 18 months ago. Amos requested the use of value 0x01 for ALPN and 0x02
> for SNI by then, though I don't know if in the end he implemlented
> anything. Same for Dave who wanted to implement them in the protocol.
> 
> Guys, for a bit of context, Erik proposes a patch to implement SNI on
> PP2. If nobody implemented anything yet, maybe it's best to continue with
> 0x23 and so on for now. Otherwise if anything was already implemented, we'll
> stay on what was already done. Please however, do provide patches at least
> for the doc if anything was done, as it's quite hard to have to dig through
> e-mail archives to find the details :-/
> 
> Thus please just check between all of you and tell me if I apply the
> attached patch or if we need to change the ID. We absolutely need to work
> on this to define how to extend the protocol in the future and to register
> new IDs...

PP2_TYPE_AUTHORITY as 0x02 is already mentioned in your 1.5 and 1.6 PP
documents. Though I have not taken the final step of using it as a
substitute for SNI (was just about to start that actually - good timing).


AFAICT you have a good pattern started already and documented in section
2.2.


There is a bit of a pattern in the registrations so far;
 - 0x0* are transport description details.
   * (protocol type, server authoruty)

 - 0x2* are TLS specific details.
   * (version, CN)

 - 0x3* namespace ??


Both ALPN and SNI are transport description details that have been
essentially tacked onto TLS at the last minute. It makes sense to keep
them separate as transport details at other levels.

The TLS layer requires SNI to be clamped to the underlying protocols
authority value. Which means receivers will need to be verifying that
SNI matches the PP2_TYPE_AUTHORITY value anyway. Duplicating it makes
little sense.
One of the issues we are seeing with HTTP CONNECT messages is that there
are already two HTTP representations of authority to correlate both up
to TCP IP:port and down to TLS SNI. Either one being weird causes
issues. IMO copying that duplication problem into PP2 would be a mistake.

Amos

J-2 : un cadeau parfait pour maman !

[Histoire d'Or]

Pour être sûr(e) de recevoir tous nos emails, ajoutez
i...@enews.histoiredor.com à votre carnet d'adresses !Si vous ne désirez plus 
recevoir de messages électroniques Histoire
d'Or, quittez notre liste de diffusion.Un problème de visualisation ? Utilisez 
notre version en ligne.

BIJOUX   MONTRES  IDÉES CADEAUX

Pour être sûr(e) de recevoir tous nos emails, ajoutez
i...@enews.histoiredor.com à votre carnet d'adresses !Si vous ne désirez plus 
recevoir de messages
électroniques Histoire d'Or, quittez notre liste de diffusion.
Un problème de visualisation ? Utilisez notre version en ligne.

BIJOUX   MONTRES  IDÉES CADEAUX

TROUVEZ LE CADEAU IDÉAL PARMI NOS BEST SELLERS*

TROUVEZ LE CADEAU IDÉAL PARMI
NOS BEST SELLERS*

BRACELETS

BAGUES

BOUCLES D'OREILLES

COLLIERS

TOUTES NOS COLLECTIONS

BRACELETS

BAGUES

BOUCLES D'OREILLES

COLLIERS

PLUS BESOIN D'ATTENDRE
RETIREZ VOS ACHATS EN MAGASIN 2H APRÈS

Commandez
en ligne  Recevez
un message  Retirez sous 2H
en magasin

EN SAVOIR PLUS

TOUTES NOS COLLECTIONS

PLUS BESOIN D'ATTENDRE
RETIREZ VOS ACHATS
EN MAGASIN 2H APRÈS
Commandez
en ligne

Recevez
un messagee

Retirez sous 2H
en magasin

Retrait sous 2H
en magasin  Livraison gratuite
à partir de 49€

30 jours pour
changer d'avis  Paiement
100% sécurité

Nos conseillers au 09 69 32 36 19

* Meilleures ventes
Histoire d'Or respecte votre vie privée. Si vous avez reçu ce
message, c'est parce que vous nous avez communiqué votre adresse
email et que vous avez accepté de recevoir une newsletter de la part
de Histoire d'Or. En application de la loi "informatique et
libertés" du 06/01/1978, vous disposez d'un droit d'accès, de
rectification et d'opposition sur les données vous concernant qui
peut s'exercer par courrier à l'adresse suivante : Histoire d'Or -
Service clients - 7 rue Saint Georges - 75009 Paris Vous recevez cet
e-mail car vous êtes abonné à la newsletter Histoire d'Or ou êtes
titulaire de la carte de fidélité Histoire d'Or.
Avec plus de 350 points de vente, Histoire d'Or vous propose une
large gamme de bijoux en or et argent. Les marques de montres les
plus prestigieuses y sont distribuées. Dans un espace intime et
convivial, une équipe de professionnels se tient à votre disposition
pour vous guider dans votre choix. Pour satisfaire au mieux votre
demande, nous disposons d'un atelier de réparation, transformation et
création qui réalisera pour vous le bijou de vos rêves ! Votre
satisfaction est notre préoccupation majeure.Si vous ne désirez plus recevoir 
de messages électroniques Histoire
d'Or, quittez notre liste de diffusion.

Retrait sous 2H
en magasin
Livraison gratuite
à partir de 49€
30 jours pour
changer d'avis
Paiement 100%
sécurité
Nos conseillers
au 09 69 32 36 19

* Meilleures ventes
Histoire d'Or respecte votre vie privée. Si vous avez reçu ce
message, c'est parce que vous nous avez communiqué votre adresse
email et que vous avez accepté de recevoir une newsletter de la part
de Histoire d'Or. En application de la loi "informatique et
libertés" du 06/01/1978, vous disposez d'un droit d'accès, de
rectification et d'opposition sur les données vous concernant qui
peut s'exercer par courrier à l'adresse suivante : Histoire d'Or -
Service clients - 7 rue Saint Georges - 75009 Paris Vous recevez cet
e-mail car vous êtes abonné à la newsletter Histoire d'Or ou êtes
titulaire de la carte de fidélité Histoire d'Or.
Avec plus de 350 points de vente, Histoire d'Or vous propose une
large gamme de bijoux en or et argent. Les marques de montres les
plus prestigieuses y sont distribuées. Dans un espace intime et
convivial, une équipe de professionnels se tient à votre disposition
pour vous guider dans votre choix. Pour satisfaire au mieux votre
demande, nous disposons d'un atelier de réparation, transformation et
création qui réalisera pour vous le bijou de vos rêves ! Votre
satisfaction est notre préoccupation majeure.Si vous ne désirez plus recevoir 
de messages électroniques Histoire
d'Or, quittez notre liste de diffusion.

Glass clamps in stainless steel &Precision Metal investment casting与您共享了相册。

[Glass clamps in stainless steel &Precision Metal investment casting]

Dear Sir,

Nice to know you through website.

We know you purchasing castings from China,so our factory hope to have a  
chance on our cooperation.


We mainly produce lost-wax casting for steel parts. We have own CNC  
machining shop. We specialize in this field for several years, with good  
quality and pretty competitive price.


Any questions and enquiries will be highly regarded. Just email us the  
drawing and detailed requirement, you will get a complete quotation with  
technical analysis within 24 hours.  FREE SAMPLES can be sent on request.


Reply me, let“s talk more!

Thanks and best regards,

Yang Shengwu
General Manager
Add:  Linqing,Shandong, China

**
From: Flying ants company (Professional global business promotion team)

If you need to product promotion, please reply to product promotion  
consultation


Global Business Development ！

***

https://picasaweb.google.com/lh/sredir?uname=108865837464345402962&target=ALBUM&id=6163517250373878497&authkey=Gv1sRgCL7NxPbZ0rKmFg&invite=CJjZ_9cD&feat=email

Re: [PATCH] BUG/MEDIUM: stats: show servers state may show an servers from another backend

[Willy Tarreau]

On Fri, May 27, 2016 at 12:06:45AM +0200, Cyril Bonté wrote:
> Olivier Doucet reported that "show servers state" was producing an invalid
> output with some configurations where nbproc > 1.
(...)

merged into 1.7+1.6. Thanks Cyril!

Willy

[PATCH] BUG/MEDIUM: stats: show servers state may show an servers from another backend

[Cyril Bonté]

Olivier Doucet reported that "show servers state" was producing an invalid
output with some configurations where nbproc > 1.

Indeed, commit 76a99784f4 fixed some issues but unfortunately introduced a
regression when a backend bound to the same process as the stats socket and a
previous backend is bound to another one.

For example :
  global
daemon
nbproc 2
stats socket /var/run/haproxy-1.sock process 1
stats socket /var/run/haproxy-2.sock process 2

  listen proc1
bind 127.0.0.1:9001
bind-process 1
server WRONG 127.0.0.1:80

  listen proc2
bind 127.0.0.1:9002
bind-process 2
server RIGHT 127.0.0.1:80

Requesting "show servers state" on /var/run/haproxy-2.sock was producing a line
like :
3 proc2 1 WRONG 127.0.0.1 2 0 1 1 4 1 0 2 0 0 0 0

whereas the line below was awaited :
3 proc2 1 RIGHT 127.0.0.1 2 0 1 1 5 1 0 2 0 0 0 0

This was caused by the initialization of the server loop too early, before the
bind_proc filtering whereas it should be done after.

This fix should be backported to 1.6, where the regression has unfortunately
been backported.
---
 src/dumpstats.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/dumpstats.c b/src/dumpstats.c
index 19e2688..47fc4bc 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -3076,6 +3076,9 @@ static int dump_servers_state(struct stream_interface 
*si, struct chunk *buf)
if (appctx->ctx.server_state.px->bind_proc && 
!(appctx->ctx.server_state.px->bind_proc & (1UL << (relative_pid - 1
return 1;
 
+   if (!appctx->ctx.server_state.sv)
+   appctx->ctx.server_state.sv = appctx->ctx.server_state.px->srv;
+
for (; appctx->ctx.server_state.sv != NULL; appctx->ctx.server_state.sv 
= srv->next) {
srv = appctx->ctx.server_state.sv;
srv_addr[0] = '\0';
@@ -3178,8 +3181,6 @@ static int stats_dump_servers_state_to_buffer(struct 
stream_interface *si)
 
for (; appctx->ctx.server_state.px != NULL; appctx->ctx.server_state.px 
= curproxy->next) {
curproxy = appctx->ctx.server_state.px;
-   if (!appctx->ctx.server_state.sv)
-   appctx->ctx.server_state.sv = 
appctx->ctx.server_state.px->srv;
/* servers are only in backends */
if (curproxy->cap & PR_CAP_BE) {
if (!dump_servers_state(si, &trash))
-- 
2.8.1

Re: "show servers state" wrong since HAProxy 1.6.5

[Olivier Doucet]

Hi Cyril,


2016-05-26 19:12 GMT+02:00 Cyril Bonté :

> Hi again,
>
> Le 26/05/2016 11:45, Cyril Bonté a écrit :
>
>> Hi Olivier,
>>
>> De: "Olivier Doucet" 
>>> À: "HAProxy" 
>>> Envoyé: Jeudi 26 Mai 2016 11:25:31
>>> Objet: "show servers state" wrong since HAProxy 1.6.5
>>>
>>>
>>> Hello,
>>> Starting with HAProxy 1.6.5, I have troubles with "show servers
>>> state" that returns me wrong data (backend servers are mixed up).
>>>
>>> I have nbproc > 1 and I bind one socket to each core.
>>>
>>> I narrowed it to a very simple config file to reproduce the issue :
>>> https://gist.github.com/odoucet/f59a23c29c8fb21fe58d2ec9dd53a685
>>>
>>> As you can see, backends are mixed up when interrogating socket #3.
>>>
>>> I tested the exact same config with version 1.6.3 and output is OK,
>>> so this is definitely a bug introduced in latest version.
>>>
>>
>> Thanks for the report.
>> Unfortunately, it's possible I introduced a regression with this commit :
>>
>> http://www.haproxy.org/git?p=haproxy.git;a=commit;h=76a99784f4ced2529e35469ccaa8e803ca397e86
>>
>> Without looking at the code, I think I know where.
>> I'll work on this tonight, after work.
>>
>
> As I thought after looking at the code, there was an initialization code
> left before the "bind_proc" check.
>
> Can you try this small patch to confirm it will work with all the
> configurations you may think of ?
>
> I'm not fond of the code structure, so it's possible I won't provide the
> patch as is for the merge request.



Do not know about the style of your patch, but it works :) Tested two
different config involving nbproc > 1 and all seems OK.

Olivier

Re: "show servers state" wrong since HAProxy 1.6.5

[Cyril Bonté]

Hi again,

Le 26/05/2016 11:45, Cyril Bonté a écrit :

Hi Olivier,


De: "Olivier Doucet" 
À: "HAProxy" 
Envoyé: Jeudi 26 Mai 2016 11:25:31
Objet: "show servers state" wrong since HAProxy 1.6.5


Hello,
Starting with HAProxy 1.6.5, I have troubles with "show servers
state" that returns me wrong data (backend servers are mixed up).

I have nbproc > 1 and I bind one socket to each core.

I narrowed it to a very simple config file to reproduce the issue :
https://gist.github.com/odoucet/f59a23c29c8fb21fe58d2ec9dd53a685

As you can see, backends are mixed up when interrogating socket #3.

I tested the exact same config with version 1.6.3 and output is OK,
so this is definitely a bug introduced in latest version.


Thanks for the report.
Unfortunately, it's possible I introduced a regression with this commit :
http://www.haproxy.org/git?p=haproxy.git;a=commit;h=76a99784f4ced2529e35469ccaa8e803ca397e86

Without looking at the code, I think I know where.
I'll work on this tonight, after work.


As I thought after looking at the code, there was an initialization code 
left before the "bind_proc" check.


Can you try this small patch to confirm it will work with all the 
configurations you may think of ?


I'm not fond of the code structure, so it's possible I won't provide the 
patch as is for the merge request.



--
Cyril Bonté
diff --git a/src/dumpstats.c b/src/dumpstats.c
index 19e2688..1a3c42a 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -3076,6 +3076,9 @@ static int dump_servers_state(struct stream_interface *si, struct chunk *buf)
 	if (appctx->ctx.server_state.px->bind_proc && !(appctx->ctx.server_state.px->bind_proc & (1UL << (relative_pid - 1
 		return 1;
 
+if (!appctx->ctx.server_state.sv)
+appctx->ctx.server_state.sv = appctx->ctx.server_state.px->srv;
+
 	for (; appctx->ctx.server_state.sv != NULL; appctx->ctx.server_state.sv = srv->next) {
 		srv = appctx->ctx.server_state.sv;
 		srv_addr[0] = '\0';
@@ -3178,8 +3181,6 @@ static int stats_dump_servers_state_to_buffer(struct stream_interface *si)
 
 	for (; appctx->ctx.server_state.px != NULL; appctx->ctx.server_state.px = curproxy->next) {
 		curproxy = appctx->ctx.server_state.px;
-		if (!appctx->ctx.server_state.sv)
-			appctx->ctx.server_state.sv = appctx->ctx.server_state.px->srv;
 		/* servers are only in backends */
 		if (curproxy->cap & PR_CAP_BE) {
 			if (!dump_servers_state(si, &trash))

Re: Lua converter not working in 1.6.5 with Lua 5.3.2

[Willy Tarreau]

On Tue, May 24, 2016 at 02:19:06PM -0400, Michael Ezzell wrote:
> I'm trying to create a Lua converter, but every time I try to call the
> converter, I get this:
> 
> May 24 17:59:34 localhost haproxy[31077]: Lua converter 'testconv': runtime
> error: attempt to call a nil value.
> 
> I've simplified this down to a minimal test case:
> 
> --
> 
> testfn = function(str)
> core.Alert("function was called")
> core.Alert("arg was " .. str)
> return str
> end
> 
> core.register_converters('testconv',testfn)
> 
> core.Alert("does this function work? " .. testfn('yes'))
> 
> --
> 
> When the proxy starts, the function itself is valid, it behaves as expected.
> 
> [alert] 144/180532 (31345) : function was called
> [alert] 144/180532 (31345) : arg was yes
> [alert] 144/180532 (31345) : does this function work? yes
> 
> But when I try to use it, like this (in a frontend)...
> 
>http-request set-header X-Test %[str("test"),lua.testconv]
> 
> ...it is as if the reference to the function has been... misplaced.
> 
> May 24 18:05:59 localhost haproxy[31346]: Lua converter 'testconv': runtime
> error: attempt to call a nil value.
> 
> ...and, of course, the X-Test header is added but has no value.
> 
> Am I doing it wrong, or is there something not right, here?  Verified with
> a clean build in a new directory.

I'm not good at Lua but I don't see anything wrong with your code above.
I suspect a bug instead. I'm CCing Thierry in case he has any idea about
it.

Willy

Re: Bug when loading multiple configuration files

[Willy Tarreau]

Hi Ben,

On Wed, May 25, 2016 at 08:41:53AM +0100, Ben Cabot wrote:
> Sorry I forgot include the build details. The configuration its self
> does not seem to matter, you get the error if you if you load 2 empty
> files or 2 with any listen or frontend / backend configurations. Its
> just the fact you are loading 2 configuration files that causes the
> problem.

Thanks for reporting this. In fact it's interesting because this cleanup
patch has uncovered a real bug. Look at readcfgfile() in cfgparse.c, the
parsers are registered for each file. It just had the effect of wasting
memory and slightly slowing down the config parser as the number of files
increased, but now it fails. One more reason to keep it, and maybe even
to backport it in the end.

I've merged the attached patch to fix it.

Thanks,
Willy
>From 659fbf02300b721adef3de74a3c1a8e4d0851080 Mon Sep 17 00:00:00 2001
From: Willy Tarreau 
Date: Thu, 26 May 2016 17:55:28 +0200
Subject: BUG/MEDIUM: config: fix multiple declaration of section parsers

Ben Cabot reported that after commit 5e4261b ("CLEANUP: config:
detect double registration of a config section") recently introduced
in 1.7-dev, it's not possible anymore to load multiple configuration
files. Bryan Talbot provided a simple reproducer to exhibit the issue.

It turns out that function readcfgfile() registers new parsers for
section keywords for each new file. In addition to being useless, this
has the negative effect of wasting memory and slowing down the config
parser as the number of configuration files increases.

This fix only needs to be backported if/where the commit above is
backported.
---
 src/cfgparse.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index 9b76465..fed5bd5 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -6968,19 +6968,6 @@ int readcfgfile(const char *file)
return -1;
}
 
-   /* Register internal sections */
-   if (!cfg_register_section("listen",   cfg_parse_listen) ||
-   !cfg_register_section("frontend", cfg_parse_listen) ||
-   !cfg_register_section("backend",  cfg_parse_listen) ||
-   !cfg_register_section("defaults", cfg_parse_listen) ||
-   !cfg_register_section("global",   cfg_parse_global) ||
-   !cfg_register_section("userlist", cfg_parse_users)  ||
-   !cfg_register_section("peers",cfg_parse_peers)  ||
-   !cfg_register_section("mailers",  cfg_parse_mailers) ||
-   !cfg_register_section("namespace_list",cfg_parse_netns) ||
-   !cfg_register_section("resolvers", cfg_parse_resolvers))
-   return -1;
-
if ((f=fopen(file,"r")) == NULL) {
free(thisline);
return -1;
@@ -9132,6 +9119,22 @@ void cfg_unregister_sections(void)
}
 }
 
+__attribute__((constructor))
+static void cfgparse_init(void)
+{
+   /* Register internal sections */
+   cfg_register_section("listen", cfg_parse_listen);
+   cfg_register_section("frontend",   cfg_parse_listen);
+   cfg_register_section("backend",cfg_parse_listen);
+   cfg_register_section("defaults",   cfg_parse_listen);
+   cfg_register_section("global", cfg_parse_global);
+   cfg_register_section("userlist",   cfg_parse_users);
+   cfg_register_section("peers",  cfg_parse_peers);
+   cfg_register_section("mailers",cfg_parse_mailers);
+   cfg_register_section("namespace_list", cfg_parse_netns);
+   cfg_register_section("resolvers",  cfg_parse_resolvers);
+}
+
 /*
  * Local variables:
  *  c-indent-level: 8
-- 
1.7.12.1

Re: [PATCH] [RFC]/MINOR: connection: Add server name to proxy protocol v2 header.

[Willy Tarreau]

On Thu, May 26, 2016 at 10:20:36AM -0400, Erik Seres wrote:
> Hi Willy,
> 
> Attached is my updated patch per your styling update request.

Thanks Erik. I'm now CCing Dave and Amos, both of whom worked on this
18 months ago. Amos requested the use of value 0x01 for ALPN and 0x02
for SNI by then, though I don't know if in the end he implemlented
anything. Same for Dave who wanted to implement them in the protocol.

Guys, for a bit of context, Erik proposes a patch to implement SNI on
PP2. If nobody implemented anything yet, maybe it's best to continue with
0x23 and so on for now. Otherwise if anything was already implemented, we'll
stay on what was already done. Please however, do provide patches at least
for the doc if anything was done, as it's quite hard to have to dig through
e-mail archives to find the details :-/

Thus please just check between all of you and tell me if I apply the
attached patch or if we need to change the ID. We absolutely need to work
on this to define how to extend the protocol in the future and to register
new IDs...

Thanks!
Willy

>From ee5b141df994c8fe42f8f2d85aa20a87dc10ca19 Mon Sep 17 00:00:00 2001
From: Erik Seres 
Date: Thu, 12 May 2016 11:05:14 +0200
Subject: [PATCH] [RFC]/MINOR: connection: Add server name to proxy protocol v2
 header.

If the client provides the server name it intends to connect to, per RFC3546, 
Section 3.1. Server Name Indication, this patch will pass the server name onto 
the backend server as part of the proxy protocol v2 header.

The patch defines the new SSL subtype PP2_TYPE_SSL_SNI and the corresponding 
flag PP2_CLIENT_SNI to accomplish this in an additional TLV.
---
 doc/proxy-protocol.txt | 7 +++
 include/proto/ssl_sock.h   | 1 +
 include/types/connection.h | 2 ++
 src/connection.c   | 5 +
 src/ssl_sock.c | 9 +
 5 files changed, 24 insertions(+)

diff --git a/doc/proxy-protocol.txt b/doc/proxy-protocol.txt
index 472dcb2..499a4e2 100644
--- a/doc/proxy-protocol.txt
+++ b/doc/proxy-protocol.txt
@@ -530,6 +530,7 @@ The following types have already been registered for the 
 field :
 #define PP2_TYPE_SSL0x20
 #define PP2_SUBTYPE_SSL_VERSION 0x21
 #define PP2_SUBTYPE_SSL_CN  0x22
+#define PP2_SUBTYPE_SSL_SNI 0x23
 #define PP2_TYPE_NETNS  0x30
 
 
@@ -552,6 +553,7 @@ indicating which element is present :
#define PP2_CLIENT_SSL   0x01
#define PP2_CLIENT_CERT_CONN 0x02
#define PP2_CLIENT_CERT_SESS 0x04
+   #define PP2_CLIENT_SNI   0x08
 
 Note, that each of these elements may lead to extra data being appended to
 this TLV using a second level of TLV encapsulation. It is thus possible to
@@ -566,6 +568,11 @@ PP2_CLIENT_CERT_CONN indicates that the client provided a 
certificate over the
 current connection. PP2_CLIENT_CERT_SESS indicates that the client provided a
 certificate at least once over the TLS session this connection belongs to.
 
+PP2_CLIENT_SNI flag indicates that the client provided a server name according
+to the Server Name Indication TLS extension. When this field is present, the
+string representation of the intended server name is appended at the end of the
+field in the TLV format using the type PP2_SUBTYPE_SSL_SNI.
+
 In all cases, the string representation (in UTF8) of the Common Name field
 (OID: 2.5.4.3) of the client certificate's DistinguishedName, is appended
 using the TLV format and the type PP2_SUBTYPE_SSL_CN.
diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
index cb9a1e9..a5a05f0 100644
--- a/include/proto/ssl_sock.h
+++ b/include/proto/ssl_sock.h
@@ -53,6 +53,7 @@ void ssl_sock_free_ca(struct bind_conf *bind_conf);
 const char *ssl_sock_get_cipher_name(struct connection *conn);
 const char *ssl_sock_get_proto_version(struct connection *conn);
 char *ssl_sock_get_version(struct connection *conn);
+char *ssl_sock_get_servername(struct connection *conn);
 void ssl_sock_set_servername(struct connection *conn, const char *hostname);
 int ssl_sock_get_cert_used_sess(struct connection *conn);
 int ssl_sock_get_cert_used_conn(struct connection *conn);
diff --git a/include/types/connection.h b/include/types/connection.h
index dfbff6a..3159085 100644
--- a/include/types/connection.h
+++ b/include/types/connection.h
@@ -335,6 +335,7 @@ struct proxy_hdr_v2 {
 #define PP2_TYPE_SSL   0x20
 #define PP2_TYPE_SSL_VERSION   0x21
 #define PP2_TYPE_SSL_CN0x22
+#define PP2_TYPE_SSL_SNI   0x23
 #define PP2_TYPE_NETNS 0x30
 
 #define TLV_HEADER_SIZE  3
@@ -355,6 +356,7 @@ struct tlv_ssl {
 #define PP2_CLIENT_SSL   0x01
 #define PP2_CLIENT_CERT_CONN 0x02
 #define PP2_CLIENT_CERT_SESS 0x04
+#define PP2_CLIENT_SNI   0x08
 
 #endif /* _TYPES_CONNECTION_H */
 
diff --git a/src/connection.c b/src/connection.c
index 330f3ef..29c45d6 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -820,6 +820,11 @@ int make_proxy_line

Re: [PATCH] [RFC]/MINOR: connection: Add server name to proxy protocol v2 header.

[Erik Seres]

Hi Willy,

Attached is my updated patch per your styling update request.

Thanks,
Erik



On 2016 May 26 Thu at 08:40:00, Willy Tarreau (w...@1wt.eu) wrote:


Hi Erik,

sorry for the long delay.

On Thu, May 12, 2016 at 11:26:29AM +0200, Erik Seres wrote:
> If the client provides the server name it intends to connect to, per
RFC3546,
> Section 3.1. Server Name Indication, this patch will pass the server name
> onto the backend server as part of the proxy protocol v2 header.
>
> The patch defines the new SSL subtype PP2_TYPE_SSL_SNI and the
corresponding
> flag PP2_CLIENT_SNI to accomplish this in an additional TLV.
>
> Please review.

I think this is OK technically speaking. And it's something we've indeed
been
missing. It is also important to note that even with this there is no way
for
haproxy to extract the SNI information from the PP header, but I don't see
how to do this cleanly and efficiently for now.

I just have one minor comment regarding a style issue (which is not yours
but comes from the few lines you copied a few lines above) :

diff --git a/src/connection.c b/src/connection.c
index 330f3ef..f7efac3 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -820,6 +820,11 @@ int make_proxy_line_v2(char *buf, int buf_len, struct
server *srv, struct connec
ssl_tlv_len += make_tlv(&buf[ret+ssl_tlv_len], (buf_len - ret -
ssl_tlv_len), PP2_TYPE_SSL_CN, cn_trash->len, cn_trash->str);
}
}
+ value = ssl_sock_get_servername(remote);
+ if (value) {
+ tlv->client |= PP2_CLIENT_SNI;
+ ssl_tlv_len += make_tlv(&buf[ret+ssl_tlv_len], (buf_len-ret-ssl_tlv_len),
PP2_TYPE_SSL_SNI, strlen(value), value);
+ }

Please always put spaces around operators above, that makes expressions
much more readable.

Otherwise I'm fine with merging it.

Regards,
Willy


0001-RFC-MINOR-connection-Add-server-name-to-proxy-protoc.patch
Description: Binary data

Re: [PATCH] [RFC]/MINOR: connection: Add server name to proxy protocol v2 header.

[Willy Tarreau]

Hi Erik,

sorry for the long delay.

On Thu, May 12, 2016 at 11:26:29AM +0200, Erik Seres wrote:
> If the client provides the server name it intends to connect to, per RFC3546,
> Section 3.1. Server Name Indication, this patch will pass the server name
> onto the backend server as part of the proxy protocol v2 header.
> 
> The patch defines the new SSL subtype PP2_TYPE_SSL_SNI and the corresponding
> flag PP2_CLIENT_SNI to accomplish this in an additional TLV.
> 
> Please review.

I think this is OK technically speaking. And it's something we've indeed been
missing. It is also important to note that even with this there is no way for
haproxy to extract the SNI information from the PP header, but I don't see
how to do this cleanly and efficiently for now.

I just have one minor comment regarding a style issue (which is not yours
but comes from the few lines you copied a few lines above) :

diff --git a/src/connection.c b/src/connection.c
index 330f3ef..f7efac3 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -820,6 +820,11 @@ int make_proxy_line_v2(char *buf, int buf_len, struct 
server *srv, struct connec
ssl_tlv_len += 
make_tlv(&buf[ret+ssl_tlv_len], (buf_len - ret - ssl_tlv_len), PP2_TYPE_SSL_CN, 
cn_trash->len, cn_trash->str);
}
}
+   value = ssl_sock_get_servername(remote);
+   if (value) {
+   tlv->client |= PP2_CLIENT_SNI;
+   ssl_tlv_len += make_tlv(&buf[ret+ssl_tlv_len], 
(buf_len-ret-ssl_tlv_len), PP2_TYPE_SSL_SNI, strlen(value), value);
+   }

Please always put spaces around operators above, that makes expressions
much more readable.

Otherwise I'm fine with merging it.

Regards,
Willy

unsubscribe

[Joe Chiang]

-- 
Thanks,
Joe

Re: Minor - patch 1.6.x - Fix some warnings in Connection.c

[Jonathan Fisher]

Omg haha I'm an oaf. Thanks! I'm surprised that also didn't cause another
warning.
On May 26, 2016 12:19 AM, "Willy Tarreau"  wrote:

> Hi Jonathan,
>
> On Tue, May 24, 2016 at 05:04:16AM -0500, Jonathan Fisher wrote:
> > What's the style you prefer?
>
> This one without the double negation :-)
>
> -   if (!memcmp(line, "TCP4 ", 5) != 0) {
> +   if (memcmp(line, "TCP4 ", 5) == 0) {
>
> I've just backported it now.
>
> Cheers,
> Willy
>
>

Re: "show servers state" wrong since HAProxy 1.6.5

[Cyril Bonté]

Hi Olivier,

> De: "Olivier Doucet" 
> À: "HAProxy" 
> Envoyé: Jeudi 26 Mai 2016 11:25:31
> Objet: "show servers state" wrong since HAProxy 1.6.5
> 
> 
> Hello,
> Starting with HAProxy 1.6.5, I have troubles with "show servers
> state" that returns me wrong data (backend servers are mixed up).
> 
> I have nbproc > 1 and I bind one socket to each core.
> 
> I narrowed it to a very simple config file to reproduce the issue :
> https://gist.github.com/odoucet/f59a23c29c8fb21fe58d2ec9dd53a685
> 
> As you can see, backends are mixed up when interrogating socket #3.
> 
> I tested the exact same config with version 1.6.3 and output is OK,
> so this is definitely a bug introduced in latest version.

Thanks for the report.
Unfortunately, it's possible I introduced a regression with this commit :
http://www.haproxy.org/git?p=haproxy.git;a=commit;h=76a99784f4ced2529e35469ccaa8e803ca397e86

Without looking at the code, I think I know where.
I'll work on this tonight, after work.

Cyril

"show servers state" wrong since HAProxy 1.6.5

[Olivier Doucet]

Hello,
Starting with HAProxy 1.6.5, I have troubles with "show servers state" that
returns me wrong data (backend servers are mixed up).

I have nbproc > 1 and I bind one socket to each core.

I narrowed it to a very simple config file to reproduce the issue :
https://gist.github.com/odoucet/f59a23c29c8fb21fe58d2ec9dd53a685

As you can see, backends are mixed up when interrogating socket #3.

I tested the exact same config with version 1.6.3 and output is OK, so this
is definitely a bug introduced in latest version.

Olivier