[PATCH] FEATURE Extending PROXY protocol for SSL

[David S]

Hello--
Part of my solution uses a non-HTTP protocol.  My backend server need
L3/L4 information, so the PROXY protocol is a perfect fit.  In addition to
TCP and IP addresses, my backend server needs information from the client
SSL connection.  So, I would like to extend the PROXY protocol.
I want to keep the protocol header small, extensible, and backwards
compatible.

The current version 1 header looks like:
PROXY TCP4 1.2.3.4 2.3.4.5 5 443\r\n
 It is sent when the server keyword "send-proxy" is configured.

 I propose a Version 1-SSL that can be sent when a new server keyword
"send-proxy-ssl" is configured.
 It would look like:
PROXY SSL4 1.2.3.4 2.3.4.5 5 443 1 0 CN="certificate common name"\r\n

 The rules to follow would be:
1) If the connection is not SSL, then the original TCP4 format is used
2) The first integer after the destination port is:
   0 if not client certifcate was sent
   1 if a client certificate was sent
3) The second integer after destination port is:
   0 if the certificate verified
   X the return code from the SSL verify() function if the certificate
did not verify
4) Delimited by quotation marks, following CN=, is the Common Name from the
client certificate.

My hope is these values will solve most people's needs, and if not, this
format can be easily extended.

I intend this email to start a discussion, but I am also attaching a code
patch implementing the above.

My To Do List:
1) remove printf() in src/stream_interface.c left in for ease of testing
2) update doc/configuration.txt
3) update doc/proxy-protocol.txt

Please let me know your feedback.

--Dave
diff --git a/include/proto/connection.h b/include/proto/connection.h
index 8609f17..0fa12a9 100644
--- a/include/proto/connection.h
+++ b/include/proto/connection.h
@@ -41,7 +41,8 @@ int conn_fd_handler(int fd);
 
 /* receive a PROXY protocol header over a connection */
 int conn_recv_proxy(struct connection *conn, int flag);
-int make_proxy_line(char *buf, int buf_len, struct sockaddr_storage *src, 
struct sockaddr_storage *dst);
+int make_proxy_line(char *buf, int buf_len, struct sockaddr_storage *src, 
struct sockaddr_storage *dst,
+   int ssl_flag, int ssl_c_used, int ssl_result, const char 
*ssl_cn);
 
 /* returns true is the transport layer is ready */
 static inline int conn_xprt_ready(const struct connection *conn)
diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
index 9d891d9..51627ea 100644
--- a/include/proto/ssl_sock.h
+++ b/include/proto/ssl_sock.h
@@ -38,8 +38,12 @@ void ssl_sock_free_certs(struct bind_conf *bind_conf);
 int ssl_sock_prepare_all_ctx(struct bind_conf *bind_conf, struct proxy *px);
 int ssl_sock_prepare_srv_ctx(struct server *srv, struct proxy *px);
 void ssl_sock_free_all_ctx(struct bind_conf *bind_conf);
+int ssl_sock_is_ssl(struct connection *conn);
 const char *ssl_sock_get_cipher_name(struct connection *conn);
 const char *ssl_sock_get_proto_version(struct connection *conn);
+int ssl_sock_get_cert_used(struct connection *conn);
+const char *ssl_sock_get_common_name(struct connection *conn);
+unsigned int ssl_sock_get_verify_result(struct connection *conn);
 
 #endif /* _PROTO_SSL_SOCK_H */
 
diff --git a/include/types/connection.h b/include/types/connection.h
index 5341a86..c87d1a3 100644
--- a/include/types/connection.h
+++ b/include/types/connection.h
@@ -183,6 +183,14 @@ enum {
CO_SFL_STREAMER= 0x0002,/* Producer is continuously streaming 
data */
 };
 
+/* PROXY protocol versions */
+enum {
+   CO_PPV_NONE = 0x0001,   /* no PROXY protocol */
+   CO_PPV_V1 = 0x0002, /* PROXY protocol version 1 */
+   CO_PPV_V1_SSL = 0x0003, /* PROXY protocol version 1 with SSL info */
+   CO_PPV_V2 = 0x0004, /* PROXY protocol version 2 */
+};
+
 /* xprt_ops describes transport-layer operations for a connection. They
  * generally run over a socket-based control layer, but not always. Some
  * of them are used for data transfer with the upper layer (rcv_*, snd_*)
@@ -245,6 +253,7 @@ struct connection {
enum obj_type obj_type;   /* differentiates connection from applet 
context */
unsigned char err_code;   /* CO_ER_* */
signed short send_proxy_ofs;  /* <0 = offset to (re)send from the end, 
>0 = send all */
+   unsigned short send_proxy_version; /* PROXY protocol v1, v1_ssl, v2 */
unsigned int flags;   /* CO_FL_* */
const struct protocol *ctrl;  /* operations at the socket layer */
const struct xprt_ops *xprt;  /* operations at the transport layer */
diff --git a/include/types/server.h b/include/types/server.h
index 54ab813..ead19d7 100644
--- a/include/types/server.h
+++ b/include/types/server.h
@@ -56,6 +56,7 @@
 /* unused: 0x0200, 0x0400 */
 #define SRV_SEND_PROXY 0x0800  /* this server talks the PROXY protocol */
 #define SRV_NON_STICK  0x1000  /* never add connections allocated to this 
server to a stick table */
+#defi

Re: Spam

[Steven Le Roux]

Ok let's do the math.

search(in:spam in:lists-haproxy before:2014/04/15 after:2014/04/01)
=> 50 spam for the last 2 weeks.

This is not what I call "astounding".

I didn't even noticed their was spam :) I had to look them for.

You can set up your MTA/MUA and you won't see anything or use
gmail/ymail/whatevermail

On Mon, Apr 14, 2014 at 7:21 PM, Malcolm Turnbull
 wrote:
> I love these little political spats :-).
> Just wanted to see how long we could make the thread.
>
> +1 for Willy.
>
> Initially I must admit I thought the non-subscribe was odd...
> But after years of happy use I finally get the reasoning, its not the
> list that is the problem but the spammers - deal with spam in the
> usual fashion (at the client end).
> In my case Google does it for me 3,500 spams in the last 30 days 
> apparently
>
> Ps. HAProxy is and always will be the best open source load balancing
> proxy solution - Thanks very much.
>
>
>
>
>
>
>
>
>
>
>
>
> On 14 April 2014 18:07, Juan  Jimenez  wrote:
>>
>> On 4/14/14, 12:00 PM, "Willy Tarreau"  wrote:
>>
>>>On Mon, Apr 14, 2014 at 04:39:21PM +0100, Kobus Bensch wrote:
 I'd like to say something as a user of the software and and avid
 follower of each conversation via this list. The few spam messages that
 do come through IS NO ISSUE. Unless it is so bad it is wearing your
 delete key out. Seriously, there are other things to complain about.
>>>
>>>Thank you for confirming my beliefs Kobus :-)
>>>
>>>Willy
>>
>> That¹s anecdotal evidence. LOL!
>>
>>
>
>
>
> --
> Regards,
>
> Malcolm Turnbull.
>
> Loadbalancer.org Ltd.
> Phone: +44 (0)870 443 8779
> http://www.loadbalancer.org/
>



-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB 
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB

Re: Recommended strategy for running 1.5 in production

[Andy Walker]

That's pretty close to our method as well. We've been using haproxy for
just over a year, and started with 1.5 because of the built-in SSL
capabilities... specifically, version 1.5-dev17. We actually did a fairly
minimal amount of testing, and just started by moving a low amount of
production traffic over to it. Since then, we've slowly ramped up to our
current 120-140 million hits per day.

We've done 2 upgrades -- 1.5-dev19 and 1.5-dev22. In both instances, we
just did a bit of testing in a dev environment, and then upgraded the
passive nodes in our active/passive haproxy pairs, let them chug along for
a couple of days days, and then upgraded the others. We haven't had any
issues with any regressions, and there haven't been any real backwards
compatibility issues. The only time we needed to change our configs during
an upgrade was with the latest health code check changes, but everything
worked out just fine!

In short, we've been much more happy with haproxy -- both during upgrades
and as a whole -- than we have with all of the closed-source enterprisey
software we run.

Thanks, Willy!!


--
Andy Walker
System Administrator
FBS - creators of flexmls
3415 39th St S
Fargo, ND  58104
701-235-7300


On Mon, Apr 14, 2014 at 5:27 PM, Ramin K  wrote:

> On 4/14/2014 2:27 PM, Jonathan Matthews wrote:
>
>> Hi all -
>>
>> I've been running 1.4 for a number of years, but am pondering moving
>> some as-yet-unreleased apps to 1.5, for SSL and ACL-ish reasons.
>>
>> I'd like to ask how you, 1.5 sysadmins and devs, track the development
>> version, and how you decide which version to run in production.
>>
>> Do you just run 1.5-dev${LATEST}? The latest snapshot? Do you follow
>> the list here and cherry-pick important bug fixes?
>>
>> I don't feel I have a firm understanding of the status of the
>> different, co-existing codebases that one could call "1.5" at any
>> given time. And nor do I have the C-skills and time to review every
>> commit.
>>
>> What do /you/ do, fellow sysadmins? How do you run, upgrade and
>> maintain confidence in your chosen version of 1.5 in production?
>>
>> All opinions and information welcome!
>> Jonathan
>>
>>
> Our method was to pick an actual release (-dev19), put it on stage, and
> after a week move it to prod. Update as new releases come out, but wait a
> day or two for any major bug (dev20 was a short lived release) to shake out
> before it goes on stage. We've been running 1.5-devxx in prod for over six
> months.
>
> Our system is relatively small trafficwise and ssl termination was the
> only driver of the move to 1.5. However we are looking at making use of the
> new health check code. ymmv.
>
> Ramin
>
>

RE: redirecting based on Accept-Language

[Lukas Tribus]

Hi,


> when you say “current version”, do you mean the 1.5 dev version? I’m
> running 1.4 right now, but its not production, so I can easily
> “upgrade” if that is required …

He means latest git master, not a dev release. So you have to clone
from the git repository:

git clone http://master.formilux.org/git/people/willy/haproxy.git/

Or you can also use tonights snapshot haproxy-ss-20140414.tar.gz, which
will be build at 02:40 UTC approximately [1].



Regards,

Lukas
 

[1] http://haproxy.1wt.eu/download/1.5/src/snapshot/


  

Re: Recommended strategy for running 1.5 in production

[Ramin K]

On 4/14/2014 2:27 PM, Jonathan Matthews wrote:

Hi all -

I've been running 1.4 for a number of years, but am pondering moving
some as-yet-unreleased apps to 1.5, for SSL and ACL-ish reasons.

I'd like to ask how you, 1.5 sysadmins and devs, track the development
version, and how you decide which version to run in production.

Do you just run 1.5-dev${LATEST}? The latest snapshot? Do you follow
the list here and cherry-pick important bug fixes?

I don't feel I have a firm understanding of the status of the
different, co-existing codebases that one could call "1.5" at any
given time. And nor do I have the C-skills and time to review every
commit.

What do /you/ do, fellow sysadmins? How do you run, upgrade and
maintain confidence in your chosen version of 1.5 in production?

All opinions and information welcome!
Jonathan



Our method was to pick an actual release (-dev19), put it on stage, and 
after a week move it to prod. Update as new releases come out, but wait 
a day or two for any major bug (dev20 was a short lived release) to 
shake out before it goes on stage. We've been running 1.5-devxx in prod 
for over six months.


Our system is relatively small trafficwise and ssl termination was the 
only driver of the move to 1.5. However we are looking at making use of 
the new health check code. ymmv.


Ramin

Recommended strategy for running 1.5 in production

[Jonathan Matthews]

Hi all -

I've been running 1.4 for a number of years, but am pondering moving
some as-yet-unreleased apps to 1.5, for SSL and ACL-ish reasons.

I'd like to ask how you, 1.5 sysadmins and devs, track the development
version, and how you decide which version to run in production.

Do you just run 1.5-dev${LATEST}? The latest snapshot? Do you follow
the list here and cherry-pick important bug fixes?

I don't feel I have a firm understanding of the status of the
different, co-existing codebases that one could call "1.5" at any
given time. And nor do I have the C-skills and time to review every
commit.

What do /you/ do, fellow sysadmins? How do you run, upgrade and
maintain confidence in your chosen version of 1.5 in production?

All opinions and information welcome!
Jonathan

Re: redirecting based on Accept-Language

[Marc Fournier]

when you say “current version”, do you mean the 1.5 dev version?   I’m running 
1.4 right now, but its not production, so I can easily “upgrade” if that is 
required …


On Apr 14, 2014, at 12:30 , Thierry FOURNIER  wrote:

> Hi Marc,
> 
> This dev is done in the current haproxy version. The keyword is
> "language", this is the documentation:
> 
>   language([,])
>  Returns the value with the highest q-factor from a list as
>  extracted from the "accept-language" header using "req.fhdr".
>  Values with no q-factor have a q-factor of 1. Values with a
>  q-factor of 0 are dropped. Only values which belong to the list of
>  semi-colon delimited  will be considered. If no value
>  matches the given list and a default value is provided, it is
>  returned. Note that language names may have a variant after a dash
>  ('-'). If this variant is present in the list, it will be matched,
>  but if it is not, only the base language is checked. The match is
>  case-sensitive, and the output string is always one of those
>  provided in arguments. The ordering of arguments is meaningless,
>  only the ordering of the values in the request counts, as the
>  first value among multiple sharing the same q-factor is used. 
> 
>  Example :
> 
>  # The "language" keyword must take the list of all language that
>  # your load balanced web site support. The list of matched
>  # language must contain all RTL languages.
>  acl rtl req.fhdr(accept-language),language (de;es;fr;en;ar) ar
>  use_backend rtl if rtl default_backend ltr
> 
> Can you test this feature ?
> 
> Thierry
> 
> 
> On Thu, 10 Apr 2014 11:00:38 +0200
> Willy Tarreau  wrote:
> 
>> On Wed, Apr 09, 2014 at 01:50:28PM -0700, Marc Fournier wrote:
>>> nginx has a module for doing this 
>>> (http://wiki.nginx.org/AcceptLanguageModule) that appears to work on a 
>>> ?first match? basis:
>>> 
>>> ==
>>> set_from_accept_language $lang en ja pl;
>>> ==
>>> 
>>> so site supports en/ja/pl ? $lang variable set based on the first
>>> Accept-Languages value that matches that list ? if no match, default to the
>>> first one (en) ?
>>> 
>>> This might be more then could be done in the config file though, if you want
>>> to honor the q= prioritizer, but that is just a method of grouping, from 
>>> what
>>> I?ve read in RFC2616 ? your examples above, for instance, would translate 
>>> as:
>> 
>> You *must* honnor "q=" because "q=0" means that you won't accept the
>> associated value. That's what haproxy does with accept-encoding for
>> example.
>> 
 zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4,ar
>>> 
>>> zh-TW;q=1,zh;q=0.8,en-US;q=0.6,en;q=0.4,ar;q=1
>>> 
>>> which would then sort out to:
>>> 
>>> zh-TW,ar,zh,en-US,en
>>> 
>>> Of course, that assumes I?m reading how it works from RFC2616 correctly ?
>>> without any q= value, everything defaults to 1 and is parsed ?in hte order
>>> presented? ? the q= modifier provides a sort order by weighting everything
>>> from ?most desired? to ?least desired? ?
>>> 
>>> Hrmmm ? a bit messy, but what I could probably do is use nginx in front of
>>> haproxy to set a cookie that I could read in haproxy and redirect 
>>> accordingly
>>> ? which I may need to do anyway, to support https:// ? 
>>> 
>>> And yes, I could use nginx to do the load balancing too, but I?m using
>>> haproxy?s stats interface for load monitoring / alerting ? I?d rather avoid
>>> using nginx if I can, since it just adds one more layer ...
>> 
>> Matching a series of q-values is very easy, the difficulty is in defining
>> how we'd like the accepted values to be configured in order to apply the
>> match.
>> 
>> Thierry proposed me something like a sample fetch which would take a
>> semi-colon delimited list of languages. I don't know if that's something
>> acceptable, as I still find that it's not obvious to configure, but it
>> would permit every possible combination. For example you would have :
>> 
>>   use_backend en if  { 
>> req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en)  en en-US }
>>   use_backend zh if  { 
>> req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en)  zh zh-TW }
>>   use_backend ar if  { 
>> req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en)  ar }
>> 
>> So that would extract the complete accept-language header, apply the 
>> filtering
>> from the supported list and pick the preferred one, then match it against a 
>> set
>> of strings.
>> 
>> The benefit of applying it as a converter is that it will be usable as
>> well for accept, accept-charset and accept-encoding.
>> 
>> If that's something you think is acceptable in terms of configuration, I
>> believe it's really not complicated to do given that we already have the
>> code to pick a preferred value in a q-list.
>> 
>> Willy
>> 
>> 

Re: src_inc_gpc0 not working with IPv4 source and IPv6 stick-tables

[Thierry FOURNIER]

On Fri, 11 Apr 2014 16:50:59 +0200
Willy Tarreau  wrote:

> Hi Apollon,
> 
> On Fri, Apr 11, 2014 at 05:37:00PM +0300, Apollon Oikonomopoulos wrote:
> > Hi,
> > 
> > While experimenting with counters in a dual-stack setup, I noticed that 
> > src_inc_gpc0 does not seem to work for IPv4 clients looked up against 
> > type ipv6 stick-tables. The following configuration:
> > 
> >  global
> >  log 127.0.0.1local0
> >  user haproxy
> >  group haproxy
> >  stats socket /var/run/haproxy.sock user root group root level admin
> >  
> >  frontend test
> >  mode http
> >  bind 127.0.0.1:
> >  bind ::1:
> >  stick-table type ipv6 size 1k expire 1h store gpc0,http_req_rate(5m)
> >  tcp-request connection track-sc0 src
> >  redirect prefix http://example.com if { src_inc_gpc0 ge 0 }
> > 
> > with a 1.5-dev22 instance and the following scenario:
> > 
> >  $ for i in {1..4}; do curl -6 http://localhost:/; done
> >  $ for i in {1..4}; do curl -4 http://localhost:/; done
> > 
> > yields these results:
> > 
> >  $ echo show table test | sudo socat STDIO /var/run/haproxy.sock
> >  # table: test, type: ipv6, size:1024, used:2
> >  0x17efd50: key=::1 use=0 exp=3596869 gpc0=4 http_req_rate(30)=4
> >  0x17effb0: key=:::127.0.0.1 use=0 exp=3598516 gpc0=0 
> > http_req_rate(30)=4
> > 
> > Notice that while the http_req_rate is properly calculated in both cases, 
> > gpc0
> > is not incremented for the mapped IPv4 client. Using sc0_inc_gpc0 on the 
> > other hand works as expected.
> > 
> > Any ideas?
> 
> Yes, I just checked and found that src_* use addr_to_stktable_key() which
> only returns a pointer to the original address based on its family and does
> not consider the table's type to perform a conversion.
> 
> We'd need to extend the function to support an output key type to provide a
> matching result.
> 

Hi,

Thanks for the bug repport, this is fixed in the current HAProxy version.

Thierry

Re: redirecting based on Accept-Language

[Thierry FOURNIER]

Hi Marc,

This dev is done in the current haproxy version. The keyword is
"language", this is the documentation:

   language([,])
  Returns the value with the highest q-factor from a list as
  extracted from the "accept-language" header using "req.fhdr".
  Values with no q-factor have a q-factor of 1. Values with a
  q-factor of 0 are dropped. Only values which belong to the list of
  semi-colon delimited  will be considered. If no value
  matches the given list and a default value is provided, it is
  returned. Note that language names may have a variant after a dash
  ('-'). If this variant is present in the list, it will be matched,
  but if it is not, only the base language is checked. The match is
  case-sensitive, and the output string is always one of those
  provided in arguments. The ordering of arguments is meaningless,
  only the ordering of the values in the request counts, as the
  first value among multiple sharing the same q-factor is used. 

  Example :

  # The "language" keyword must take the list of all language that
  # your load balanced web site support. The list of matched
  # language must contain all RTL languages.
  acl rtl req.fhdr(accept-language),language (de;es;fr;en;ar) ar
  use_backend rtl if rtl default_backend ltr

Can you test this feature ?

Thierry


On Thu, 10 Apr 2014 11:00:38 +0200
Willy Tarreau  wrote:

> On Wed, Apr 09, 2014 at 01:50:28PM -0700, Marc Fournier wrote:
> > nginx has a module for doing this 
> > (http://wiki.nginx.org/AcceptLanguageModule) that appears to work on a 
> > ?first match? basis:
> > 
> > ==
> > set_from_accept_language $lang en ja pl;
> > ==
> > 
> > so site supports en/ja/pl ? $lang variable set based on the first
> > Accept-Languages value that matches that list ? if no match, default to the
> > first one (en) ?
> > 
> > This might be more then could be done in the config file though, if you want
> > to honor the q= prioritizer, but that is just a method of grouping, from 
> > what
> > I?ve read in RFC2616 ? your examples above, for instance, would translate 
> > as:
> 
> You *must* honnor "q=" because "q=0" means that you won't accept the
> associated value. That's what haproxy does with accept-encoding for
> example.
> 
> > > zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4,ar
> > 
> > zh-TW;q=1,zh;q=0.8,en-US;q=0.6,en;q=0.4,ar;q=1
> > 
> > which would then sort out to:
> > 
> > zh-TW,ar,zh,en-US,en
> > 
> > Of course, that assumes I?m reading how it works from RFC2616 correctly ?
> > without any q= value, everything defaults to 1 and is parsed ?in hte order
> > presented? ? the q= modifier provides a sort order by weighting everything
> > from ?most desired? to ?least desired? ?
> > 
> > Hrmmm ? a bit messy, but what I could probably do is use nginx in front of
> > haproxy to set a cookie that I could read in haproxy and redirect 
> > accordingly
> > ? which I may need to do anyway, to support https:// ? 
> > 
> > And yes, I could use nginx to do the load balancing too, but I?m using
> > haproxy?s stats interface for load monitoring / alerting ? I?d rather avoid
> > using nginx if I can, since it just adds one more layer ...
> 
> Matching a series of q-values is very easy, the difficulty is in defining
> how we'd like the accepted values to be configured in order to apply the
> match.
> 
> Thierry proposed me something like a sample fetch which would take a
> semi-colon delimited list of languages. I don't know if that's something
> acceptable, as I still find that it's not obvious to configure, but it
> would permit every possible combination. For example you would have :
> 
>use_backend en if  { 
> req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en)  en en-US }
>use_backend zh if  { 
> req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en)  zh zh-TW }
>use_backend ar if  { 
> req.fhdr(accept-language),q-preferred(zh-TW;ar;zh;en-US;en)  ar }
> 
> So that would extract the complete accept-language header, apply the filtering
> from the supported list and pick the preferred one, then match it against a 
> set
> of strings.
> 
> The benefit of applying it as a converter is that it will be usable as
> well for accept, accept-charset and accept-encoding.
> 
> If that's something you think is acceptable in terms of configuration, I
> believe it's really not complicated to do given that we already have the
> code to pick a preferred value in a q-list.
> 
> Willy
> 
> 

Re: Spam

[Malcolm Turnbull]

I love these little political spats :-).
Just wanted to see how long we could make the thread.

+1 for Willy.

Initially I must admit I thought the non-subscribe was odd...
But after years of happy use I finally get the reasoning, its not the
list that is the problem but the spammers - deal with spam in the
usual fashion (at the client end).
In my case Google does it for me 3,500 spams in the last 30 days apparently

Ps. HAProxy is and always will be the best open source load balancing
proxy solution - Thanks very much.












On 14 April 2014 18:07, Juan  Jimenez  wrote:
>
> On 4/14/14, 12:00 PM, "Willy Tarreau"  wrote:
>
>>On Mon, Apr 14, 2014 at 04:39:21PM +0100, Kobus Bensch wrote:
>>> I'd like to say something as a user of the software and and avid
>>> follower of each conversation via this list. The few spam messages that
>>> do come through IS NO ISSUE. Unless it is so bad it is wearing your
>>> delete key out. Seriously, there are other things to complain about.
>>
>>Thank you for confirming my beliefs Kobus :-)
>>
>>Willy
>
> That¹s anecdotal evidence. LOL!
>
>



-- 
Regards,

Malcolm Turnbull.

Loadbalancer.org Ltd.
Phone: +44 (0)870 443 8779
http://www.loadbalancer.org/

Premier sur Google en 2014

[E-visibilite]

Pour vous, être présent sur Google c’est trouver de nouveaux clients.
Mais combien coûte un bon référencement ? 
http://www.e-visibilite.com/referencement3.php

Re: Spam

[Juan Jimenez]

On 4/14/14, 12:00 PM, "Willy Tarreau"  wrote:

>On Mon, Apr 14, 2014 at 04:39:21PM +0100, Kobus Bensch wrote:
>> I'd like to say something as a user of the software and and avid
>> follower of each conversation via this list. The few spam messages that
>> do come through IS NO ISSUE. Unless it is so bad it is wearing your
>> delete key out. Seriously, there are other things to complain about.
>
>Thank you for confirming my beliefs Kobus :-)
>
>Willy

That¹s anecdotal evidence. LOL!

Re: haproxy intermittently not connecting to backend

[Willy Tarreau]

On Mon, Apr 14, 2014 at 12:08:40PM -0400, Patrick Hemmer wrote:
> >> Nginx uses 499 for "client closed connection". Perhaps haproxy could use
> >> that status code as well when `option abortonclose` is used.
> > It's wrong to invent new status codes, because they'll sooner or later
> > conflict with one officially assigned (or worse, they'll become so much
> > used that they'll make it harder to improve the standards).
> RFC2616 says "HTTP status codes are extensible" and even gives a
> specific scenario how the client should handle an unregistered code
> (look for the "if an unrecognized status code of 431 is received by the
> client" example).

Yes, but this was not meant for anyone to pick unregistered codes, but for
the protocol to be extensible. More info here :

  http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-8.2

  8.2. Status Code Registry

   The HTTP Status Code Registry defines the name space for the response
   status-code token (Section 6).  The status code registry is
   maintained at .

  And 8.2.2 is even clearer about this :

   Proposals for new status codes that are not yet widely deployed ought
   to avoid allocating a specific number for the code until there is
   clear consensus that it will be registered; instead, early drafts can
   use a notation such as "4NN", or "3N0" .. "3N9", to indicate the
   class of the proposed status code(s) without consuming a number
   prematurely.

There was never any consensus for having a range of "free" status codes
just like is done with headers starting with "X-" unfortunately.

> > However here it's not as black and white. If a client manages to close
> > before the connection to the server is opened, it's generally because
> > the server takes time to accept the connection. The longer it takes,
> > the higher the number of 503 due to client aborts. What we should try
> > to avoid in my opinion is to return 503 immediately. I think that the
> > semantics of 408 are the closest to what we're expecting in terms of
> > asking the client to retry if needed, eventhough that's a different
> > technical issue. I'd rather not use plain 400 to avoid polluting the
> > real 400 that admins have a hard time trying to fix sometimes.
> I disagree with the statement that we should avoid immediate response
> when the connection is closed. Going back to RFC1945 (HTTP 1.0), we have
> this:
> "In any case, the closing of the connection by either or both parties
> always terminates the current request, regardless of its status."
> But that is HTTP 1.0, so it's validity in this case is tenuous. I
> couldn't find a similar statement in RFC2616, or anything which states
> how it should be handled when the client closes it's connection prior to
> response. I guess this is why it's a configurable option :-)

The problem is that people who documented HTTP in the past didn't necessarily
know by then that TCP was two half-connections and not a single full one.
Unless you have a hard error on a socket, you never know if the other side
is closed and TCP offers no provisions for this. TCP only says "that's all
I have to say" (ie: FIN).

In practice, many scripts or even health checks from various systems do
send a request with a FIN immediately because they have nothing more to
say. It will become even more common with TCP FastOpen where it's very
convenient to send SYN+request+FIN in a single packet and receive the
response along with the SYN-ACK and a FIN as well. Almost UDP!

> If we want to use a registered status code, I would argue in favor of
> "417" which has the following in it's description:
> "if the server is a proxy, the server has unambiguous evidence that the
> request could not be met by the next-hop server"

I thought about it, but 417 has a very specific meaning related to the
Expect header and will definitely have side effects when sent in response
to a request having an Expect header (such as the client not being able
to reformulate the request ever).

> Would it be difficult to add a parameter to the option? Such as "option
> httpclose 417" to control how haproxy responds?

It's an idea that is worth thinking about. It would be for abortonclose
though, but the idea is there. One thing I don't like with overloading
options is that in the past they were plain booleans and were cancellable
with "no" in front of them. As time goes, some options take extra args
which make them harder to cancel, or more confusing.

Maybe we could do something even better, consisting in enumerating the
long list of all events which lead to a fixed status code and make it
possible to remap them. I'm pretty sure that for some users it might be
really nice, even if it allows some to write stupid configurations.

Regards,
Willy

Re: [PATCH] Add standardized DH parameters >= 1024 bits

[Willy Tarreau]

On Mon, Apr 14, 2014 at 05:42:27PM +0200, Remi Gacogne wrote:
> If you think it may be an issue, I will gladly add the missing #ifdefs,
> but as even Debian 5 and RHEL 5 have an OpenSSL >= 0.9.8a, I am not sure
> it is needed.

So FYI, I've just tried a few different builds and found no issue for
now, so I merged it. We'll see if anyone complains, but from experience,
people running on old systems generally don't upgrade that often :-)

Thanks!
Willy

Re: haproxy intermittently not connecting to backend

[Patrick Hemmer]

*From: *Willy Tarreau 
*Sent: * 2014-04-14 11:27:59 E
*To: *Patrick Hemmer 
*CC: *haproxy@formilux.org
*Subject: *Re: haproxy intermittently not connecting to backend

> Hi Patrick,
>
> On Sat, Apr 12, 2014 at 01:38:54AM -0400, Patrick Hemmer wrote:
>> This just keeps coming back to bug me. I don't think the client closing
>> the connection should result in a 5XX code. 5XX should indicate a server
>> issue, and the client closing the connection before the server has a
>> chance to respond isn't a server issue. Only if the server doesn't
>> respond within the configured timeout should it be a 5XX.
>>
>> Nginx uses 499 for "client closed connection". Perhaps haproxy could use
>> that status code as well when `option abortonclose` is used.
> It's wrong to invent new status codes, because they'll sooner or later
> conflict with one officially assigned (or worse, they'll become so much
> used that they'll make it harder to improve the standards).
RFC2616 says "HTTP status codes are extensible" and even gives a
specific scenario how the client should handle an unregistered code
(look for the "if an unrecognized status code of 431 is received by the
client" example).

> I get your point though. I'm used to say that 5xx is an error that the
> client should not be able to induce. This is not totally right nowadays
> due to 501, nor due to web services which like to return 500 when they
> want to return "false"... But in general that's the idea.
>
> However here it's not as black and white. If a client manages to close
> before the connection to the server is opened, it's generally because
> the server takes time to accept the connection. The longer it takes,
> the higher the number of 503 due to client aborts. What we should try
> to avoid in my opinion is to return 503 immediately. I think that the
> semantics of 408 are the closest to what we're expecting in terms of
> asking the client to retry if needed, eventhough that's a different
> technical issue. I'd rather not use plain 400 to avoid polluting the
> real 400 that admins have a hard time trying to fix sometimes.
I disagree with the statement that we should avoid immediate response
when the connection is closed. Going back to RFC1945 (HTTP 1.0), we have
this:
"In any case, the closing of the connection by either or both parties
always terminates the current request, regardless of its status."
But that is HTTP 1.0, so it's validity in this case is tenuous. I
couldn't find a similar statement in RFC2616, or anything which states
how it should be handled when the client closes it's connection prior to
response. I guess this is why it's a configurable option :-)

If we want to use a registered status code, I would argue in favor of
"417" which has the following in it's description:
"if the server is a proxy, the server has unambiguous evidence that the
request could not be met by the next-hop server"

Would it be difficult to add a parameter to the option? Such as "option
httpclose 417" to control how haproxy responds?

> Any optinion on this ?
>
> Willy
>
>

Re: Spam

[William Lewis]

+1

Keep up the good work Willy

On 14 Apr 2014, at 17:00, Willy Tarreau  wrote:

> On Mon, Apr 14, 2014 at 04:39:21PM +0100, Kobus Bensch wrote:
>> I'd like to say something as a user of the software and and avid 
>> follower of each conversation via this list. The few spam messages that 
>> do come through IS NO ISSUE. Unless it is so bad it is wearing your 
>> delete key out. Seriously, there are other things to complain about.
> 
> Thank you for confirming my beliefs Kobus :-)
> 
> Willy
> 
> 

Re: Spam

[Willy Tarreau]

On Mon, Apr 14, 2014 at 04:39:21PM +0100, Kobus Bensch wrote:
> I'd like to say something as a user of the software and and avid 
> follower of each conversation via this list. The few spam messages that 
> do come through IS NO ISSUE. Unless it is so bad it is wearing your 
> delete key out. Seriously, there are other things to complain about.

Thank you for confirming my beliefs Kobus :-)

Willy

Re: [PATCH] Add standardized DH parameters >= 1024 bits

[Willy Tarreau]

On Mon, Apr 14, 2014 at 05:42:27PM +0200, Remi Gacogne wrote:
> 
> Hello Willy,
> 
> Nice speak at FRnOG 22 :)

Thanks :-)

> >> This patch adds standardized (rfc 2409 / rfc 3526) DH parameters with
> >> prime lengths of 1024, 2048, 3072, 4096, 6144 and 8192 bits, based on
> >> the private key size. As of now, static DH parameters of 1024 bits are
> >> used when no custom DH parameters are provided in the cert file,
> >> effectively reducing the strength of the key exchange to 1024 bits even
> >> when the private key is stronger than that.
> > 
> > (...)
> > 
> > Great, thank you. I'm just having a question, since I'm seeing a number
> > of openssl functions involved, have you tried them with multiple versions
> > to ensure that we don't need to add some extra #ifdefs in order not to
> > break build on older libs ? Please at least check on openssl-0.9.8 (I
> > think it's in RHEL5).
> 
> Yes, all functions exists in at least 0.9.8a. The most recently added
> ones are get_rfc_prime_(), which have been present since 0.9.8a
> (released 11 Oct 2005).
> 
> If you think it may be an issue, I will gladly add the missing #ifdefs,
> but as even Debian 5 and RHEL 5 have an OpenSSL >= 0.9.8a, I am not sure
> it is needed.

OK that seems like a good start. I believe my sparc is on openssl 0.9.7
so I'll check that as well and possibly find the related ifdef if needed.
Maybe I'll simply add a test on OPENSSL_VERSION_NUMBER.

Willy

Re: [PATCH] Add standardized DH parameters >= 1024 bits

[Remi Gacogne]

Hello Willy,

Nice speak at FRnOG 22 :)

>> This patch adds standardized (rfc 2409 / rfc 3526) DH parameters with
>> prime lengths of 1024, 2048, 3072, 4096, 6144 and 8192 bits, based on
>> the private key size. As of now, static DH parameters of 1024 bits are
>> used when no custom DH parameters are provided in the cert file,
>> effectively reducing the strength of the key exchange to 1024 bits even
>> when the private key is stronger than that.
> 
> (...)
> 
> Great, thank you. I'm just having a question, since I'm seeing a number
> of openssl functions involved, have you tried them with multiple versions
> to ensure that we don't need to add some extra #ifdefs in order not to
> break build on older libs ? Please at least check on openssl-0.9.8 (I
> think it's in RHEL5).

Yes, all functions exists in at least 0.9.8a. The most recently added
ones are get_rfc_prime_(), which have been present since 0.9.8a
(released 11 Oct 2005).

If you think it may be an issue, I will gladly add the missing #ifdefs,
but as even Debian 5 and RHEL 5 have an OpenSSL >= 0.9.8a, I am not sure
it is needed.


-- 
Rémi Gacogne

Aqua Ray
SAS au capital de 105.720 Euros
RCS Créteil 447 997 099
www.aquaray.fr

14, rue Jules Vanzuppe
94854 IVRY-SUR-SEINE CEDEX (France)
Tel : (+33) (0)1 84 04 04 05
Fax : (+33) (0)1 77 65 60 42



signature.asc
Description: OpenPGP digital signature

Re: Spam

[Kobus Bensch]

I'd like to say something as a user of the software and and avid 
follower of each conversation via this list. The few spam messages that 
do come through IS NO ISSUE. Unless it is so bad it is wearing your 
delete key out. Seriously, there are other things to complain about.

On 14/04/2014 16:11, Willy Tarreau wrote:

On Mon, Apr 14, 2014 at 02:59:48PM +, Juan  Jimenez wrote:

I will mention a couple of points and leave it at that. I靶e been
operating mailing lists for decades, I get zero spam on the ones I own by
taking simple measures to prevent it, and the subscribe/unsubscribe is so
painless than no one complains about it.

For sure, they'd have to subscribe in order to complain. Just like I
never complained to anybody about the few of my e-mails that got dropped
in the past to a few mailing lists. You see that you're going to help
someone, your e-mail is rejected and you simply think "go to hell with
your filters and keep your list closed". And these mails were lost and
so what ?


If someone wants to read and not
participate, I allow that as well by making the threads public. If they
want to ask questions and participate, I require them to subscribe because
I respect the rights of those who do accept a little bit of work in
exchange for getting value from the list.

It's exactly the problem : you don't consider those who contribute just
for the sake of helping and not getting back any value from a list. We
have some like this on this list BTW. Some of them were not subscribers
during their first e-mails and finally subscribed. That's exactly what
your filtering method prevents and I disagree with that.

If we had 100 spams a day, we could possibly change something, but at
the moment, the only reason for noticing spam is that there's low traffic
on the list.

BTW, what drives people out of the list is not spam but actually discussions.
I can say that every time there are 1 or 2 threads which last for a few
e-mails, I'm getting 2 or 3 unsubscription emails. I can predict for sure
that it will happen this evening due to this thread.

So that proves one thing :
   - spam make people complain
   - useful discussions about the work make people leave

Let's keep people complaining, while they complain they don't leave :-)

Willy





--


Trustpay Global Limited is an authorised Electronic Money Institution 
regulated by the Financial Conduct Authority registration number 900043. 
Company No 07427913 Registered in England and Wales with registered address 
130 Wood Street, London, EC2V 6DL, United Kingdom.


For further details please visit our website at www.trustpayglobal.com.

The information in this email and any attachments are confidential and 
remain the property of Trustpay Global Ltd unless agreed by contract. It is 
intended solely for the person to whom or the entity to which it is 
addressed. If you are not the intended recipient you may not use, disclose, 
copy, distribute, print or rely on the content of this email or its 
attachments. If this email has been received by you in error please advise 
the sender and delete the email from your system. Trustpay Global Ltd does 
not accept any liability for any personal view expressed in this message.

Re: haproxy intermittently not connecting to backend

[Willy Tarreau]

Hi Patrick,

On Sat, Apr 12, 2014 at 01:38:54AM -0400, Patrick Hemmer wrote:
> This just keeps coming back to bug me. I don't think the client closing
> the connection should result in a 5XX code. 5XX should indicate a server
> issue, and the client closing the connection before the server has a
> chance to respond isn't a server issue. Only if the server doesn't
> respond within the configured timeout should it be a 5XX.
> 
> Nginx uses 499 for "client closed connection". Perhaps haproxy could use
> that status code as well when `option abortonclose` is used.

It's wrong to invent new status codes, because they'll sooner or later
conflict with one officially assigned (or worse, they'll become so much
used that they'll make it harder to improve the standards).

I get your point though. I'm used to say that 5xx is an error that the
client should not be able to induce. This is not totally right nowadays
due to 501, nor due to web services which like to return 500 when they
want to return "false"... But in general that's the idea.

However here it's not as black and white. If a client manages to close
before the connection to the server is opened, it's generally because
the server takes time to accept the connection. The longer it takes,
the higher the number of 503 due to client aborts. What we should try
to avoid in my opinion is to return 503 immediately. I think that the
semantics of 408 are the closest to what we're expecting in terms of
asking the client to retry if needed, eventhough that's a different
technical issue. I'd rather not use plain 400 to avoid polluting the
real 400 that admins have a hard time trying to fix sometimes.

Any optinion on this ?

Willy

Re: Spam

[Willy Tarreau]

On Mon, Apr 14, 2014 at 02:59:48PM +, Juan  Jimenez wrote:
> I will mention a couple of points and leave it at that. I¹ve been
> operating mailing lists for decades, I get zero spam on the ones I own by
> taking simple measures to prevent it, and the subscribe/unsubscribe is so
> painless than no one complains about it.

For sure, they'd have to subscribe in order to complain. Just like I
never complained to anybody about the few of my e-mails that got dropped
in the past to a few mailing lists. You see that you're going to help
someone, your e-mail is rejected and you simply think "go to hell with
your filters and keep your list closed". And these mails were lost and
so what ?

> If someone wants to read and not
> participate, I allow that as well by making the threads public. If they
> want to ask questions and participate, I require them to subscribe because
> I respect the rights of those who do accept a little bit of work in
> exchange for getting value from the list.

It's exactly the problem : you don't consider those who contribute just
for the sake of helping and not getting back any value from a list. We
have some like this on this list BTW. Some of them were not subscribers
during their first e-mails and finally subscribed. That's exactly what
your filtering method prevents and I disagree with that.

If we had 100 spams a day, we could possibly change something, but at
the moment, the only reason for noticing spam is that there's low traffic
on the list.

BTW, what drives people out of the list is not spam but actually discussions.
I can say that every time there are 1 or 2 threads which last for a few
e-mails, I'm getting 2 or 3 unsubscription emails. I can predict for sure
that it will happen this evening due to this thread.

So that proves one thing :
  - spam make people complain
  - useful discussions about the work make people leave

Let's keep people complaining, while they complain they don't leave :-)

Willy

Re: [PATCH] Add standardized DH parameters >= 1024 bits

[Willy Tarreau]

Hi Remi,

On Mon, Apr 14, 2014 at 04:59:06PM +0200, Remi Gacogne wrote:
> 
> Hi,
> 
> This patch adds standardized (rfc 2409 / rfc 3526) DH parameters with
> prime lengths of 1024, 2048, 3072, 4096, 6144 and 8192 bits, based on
> the private key size. As of now, static DH parameters of 1024 bits are
> used when no custom DH parameters are provided in the cert file,
> effectively reducing the strength of the key exchange to 1024 bits even
> when the private key is stronger than that.

(...)

Great, thank you. I'm just having a question, since I'm seeing a number
of openssl functions involved, have you tried them with multiple versions
to ensure that we don't need to add some extra #ifdefs in order not to
break build on older libs ? Please at least check on openssl-0.9.8 (I
think it's in RHEL5).

Thanks,
Willy

Re: Spam

[Juan Jimenez]

On 4/14/14, 10:31 AM, "Willy Tarreau"  wrote:

>On Mon, Apr 14, 2014 at 02:02:46PM +, Juan  Jimenez wrote:
>> Like most people who subscribe, I do so because I
>> want to follow the discussions on the product and have more than a
>>passing
>> interest in it, especially since the current dev version addresses
>>things
>> that are needed to be useful in the configuration we are supporting.
>> Subscribe/Unsubscribe is a simple process in virtually all mailing lists
>> now. Like I said, this is 2014?
>
>Yes, and 2014 means what ? spam everywhere has become standard. OK.
>And subscribing/unsubscribing is painful and impolite for people who are
>CCed and try to respond and get rejected. It happened to me a few times
>on other lists and I simply dropped the mail I tried to send because I
>wasn't going to subscribe for this.
>
>Also, we're in 2014. You're not forced to read the discussions via the
>list, there are marc.info and gmane as well.
>
>Willy
>

I will mention a couple of points and leave it at that. I¹ve been
operating mailing lists for decades, I get zero spam on the ones I own by
taking simple measures to prevent it, and the subscribe/unsubscribe is so
painless than no one complains about it. If someone wants to read and not
participate, I allow that as well by making the threads public. If they
want to ask questions and participate, I require them to subscribe because
I respect the rights of those who do accept a little bit of work in
exchange for getting value from the list.

Juan

[PATCH] Add standardized DH parameters >= 1024 bits

[Remi Gacogne]

Hi,

This patch adds standardized (rfc 2409 / rfc 3526) DH parameters with
prime lengths of 1024, 2048, 3072, 4096, 6144 and 8192 bits, based on
the private key size. As of now, static DH parameters of 1024 bits are
used when no custom DH parameters are provided in the cert file,
effectively reducing the strength of the key exchange to 1024 bits even
when the private key is stronger than that.

The recent CVE-2014-0160 vulnerability (aka "heartbleed") and the
massive key regeneration that followed caused a lot of people to upgrade
to 2048 or even 4096 bits RSA keys, so I believe it would be a good time
to upgrade DH parameters altogether.

This patch is based on what Apache HTTPd's mod_ssl does since 2.4.7:

https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile.

Please be aware that this patch may cause an issue with some SSL/TLS
clients, mostly Java 7 or earlier, that do not support primes larger
than 1024 bits. mod_ssl advises using custom DH parameters of 1024 bits
for servers encountering this kind of issues:

https://httpd.apache.org/docs/2.4/ssl/ssl_faq.html#javadh


Please feel free to get back to me for any question or remark.


Best regards,

-- 
Rémi Gacogne

Aqua Ray
SAS au capital de 105.720 Euros
RCS Créteil 447 997 099
www.aquaray.fr

14, rue Jules Vanzuppe
94854 IVRY-SUR-SEINE CEDEX (France)
Tel : (+33) (0)1 84 04 04 05
Fax : (+33) (0)1 77 65 60 42
From 6142ec6b30a0cff26b3e5ea1aaf90ad535c4789a Mon Sep 17 00:00:00 2001
From: Remi Gacogne 
Date: Mon, 14 Apr 2014 16:47:31 +0200
Subject: [PATCH] Add standardized DH parameters >= 1024 bits

This patch adds standardized (rfc 2409 / rfc 3526)
DH parameters with prime lengths of 1024, 2048, 3072, 4096, 6144 and
8192 bits, based on the private key size.
---
 src/ssl_sock.c | 184 -
 1 file changed, 143 insertions(+), 41 deletions(-)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index a11aed2..f7c50c5 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -270,36 +270,149 @@ static int ssl_sock_switchctx_cbk(SSL *ssl, int *al, struct bind_conf *s)
 #endif /* SSL_CTRL_SET_TLSEXT_HOSTNAME */
 
 #ifndef OPENSSL_NO_DH
+
+static DH *ssl_get_dh_1024(void)
+{
+	DH *dh = DH_new();
+	if (dh) {
+		dh->p = get_rfc2409_prime_1024(NULL);
+		/* See RFC 2409, Section 6 "Oakley Groups"
+		   for the reason why we use 2 as a generator.
+		*/
+		BN_dec2bn(&dh->g, "2");
+		if (!dh->p || !dh->g) {
+			DH_free(dh);
+			dh = NULL;
+		}
+	}
+	return dh;
+}
+
+static DH *ssl_get_dh_2048(void)
+{
+	DH *dh = DH_new();
+	if (dh) {
+		dh->p = get_rfc3526_prime_2048(NULL);
+		/* See RFC 3526, Section 3 "2048-bit MODP Group"
+		   for the reason why we use 2 as a generator.
+		 */
+		BN_dec2bn(&dh->g, "2");
+		if (!dh->p || !dh->g) {
+			DH_free(dh);
+			dh = NULL;
+		}
+	}
+	return dh;
+}
+
+static DH *ssl_get_dh_3072(void)
+{
+	DH *dh = DH_new();
+	if (dh) {
+		dh->p = get_rfc3526_prime_3072(NULL);
+		/* See RFC 3526, Section 4 "3072-bit MODP Group"
+		   for the reason why we use 2 as a generator.
+		 */
+		BN_dec2bn(&dh->g, "2");
+		if (!dh->p || !dh->g) {
+			DH_free(dh);
+			dh = NULL;
+		}
+	}
+	return dh;
+}
+
+static DH *ssl_get_dh_4096(void)
+{
+	DH *dh = DH_new();
+	if (dh) {
+		dh->p = get_rfc3526_prime_4096(NULL);
+		/* See RFC 3526, Section 5 "4096-bit MODP Group"
+		   for the reason why we use 2 as a generator.
+		 */
+		BN_dec2bn(&dh->g, "2");
+		if (!dh->p || !dh->g) {
+			DH_free(dh);
+			dh = NULL;
+		}
+	}
+	return dh;
+}
+
+static DH *ssl_get_dh_6144(void)
+{
+	DH *dh = DH_new();
+	if (dh) {
+		dh->p = get_rfc3526_prime_6144(NULL);
+		/* See RFC 3526, Section 6 "6144-bit MODP Group"
+		   for the reason why we use 2 as a generator.
+		 */
+		BN_dec2bn(&dh->g, "2");
+		if (!dh->p || !dh->g) {
+			DH_free(dh);
+			dh = NULL;
+		}
+	}
+	return dh;
+}
+
+static DH *ssl_get_dh_8192(void)
+{
+	DH *dh = DH_new();
+	if (dh) {
+		dh->p = get_rfc3526_prime_8192(NULL);
+		/* See RFC 3526, Section 7 "8192-bit MODP Group"
+		   for the reason why we use 2 as a generator.
+		 */
+		BN_dec2bn(&dh->g, "2");
+		if (!dh->p || !dh->g) {
+			DH_free(dh);
+			dh = NULL;
+		}
+	}
+	return dh;
+}
+
+/* Returns Diffie-Hellman parameters matching the private key length */
+static DH *ssl_get_tmp_dh(SSL *ssl, int export, int keylen)
+{
+	DH *dh = NULL;
+	EVP_PKEY *pkey = SSL_get_privatekey(ssl);
+	int type = pkey ? EVP_PKEY_type(pkey->type) : EVP_PKEY_NONE;
+
+	if (type == EVP_PKEY_RSA || type == EVP_PKEY_DSA) {
+		keylen = EVP_PKEY_bits(pkey);
+	}
+
+	if (keylen >= 8192) {
+		dh = ssl_get_dh_8192();
+	}
+	else if (keylen >= 6144) {
+		dh = ssl_get_dh_6144();
+	}
+	else if (keylen >= 4096) {
+		dh = ssl_get_dh_4096();
+	}
+	else if (keylen >= 3072) {
+		dh = ssl_get_dh_3072();
+	}
+	else if (keylen >= 2048) {
+		dh = ssl_get_dh_2048();
+	}
+	else {
+		dh = ssl_get_dh_1024();
+	}
+
+	return dh;
+}
+
 /* Loads Diffie-Hellman parameter from a file. Returns 1 if loaded, else -1
if an error occured, and 0 if paramete

Re: Spam

[Pedro Mata-Mouros]

Jeffrey, Ian, Patrick, et al,

I feel some of your pain, but I also really feel that I want Willy 
concentrating on this amazing piece of open source, free software that is 
crucial to my job.

Often times with open source projects (myself included in the past) we get 
frustrated at the wrong person/thing.

Please consider putting this into some perspective. I’ve been a subscriber of 
this list I think for over 5 years now. The value it provides to me is really 
immense. Just the other day I was saying to one of my devops guys that this 
should be the only mailing list he should make sure he subscribed to.

I don’t mind getting the occasional spam email, when I know that this is not a 
paid service and when I know that Willy and the rest of the awesome 
contributors have lives of their own and probably even better things to do than 
start managing mailing list software and mail servers and so on.

I understand your feelings but please either respect that the author and 
contributors don’t really have the resources (time/money) to improve this 
really minor thing, or take a step forward and offer yourselves to fix the 
issue.

This is a community, it’s rude to demand without offering back.

Pedro.

On 14 Apr 2014, at 15:26, Jeffrey 'jf' Lim  wrote:

> On Mon, Apr 14, 2014 at 9:25 PM, Willy Tarreau  wrote:
>> On Mon, Apr 14, 2014 at 09:03:44AM -0400, Patrick Hemmer wrote:
>>> While I strongly disagree, I can respect your reasoning. But perhaps
>>> there are solutions other than restricting non-subscribers. I can think
>>> of these few without much thought:
>>> 1) add grey listing (http://en.wikipedia.org/wiki/Greylisting).
>> 
>> We already have some greylisting which is why we have "only" a little
>> bit of spam.
>> 
>>> 2) add a header indicating whether the sender is subscribed to the
>>> mailing list. Then anyone who wants to remain on the list can add a
>>> filter to auto-delete mail when the sender isn't on the list. I don't
>>> know the numbers, but I'd bet the valid non-subscriber mail is rare.
>> 
>> Among 2000 participants, we have 700 permanent subscribers, which means
>> that other ones unsubscribe after a few exchanges. Some people (including
>> myself) also have multiple addresses and will post from work or home
>> using a different one while they don't want to be subscribed multiple
>> times.
>> 
>>> 3) Add a spamhaus IP blacklist. While I doubt this would block any
>>> legitimate mail, it is possible. So I expect this to be met with the
>>> same resistance as only allowing subscribers.
>> 
>> We're currently using one such crappy BLs, which was the reason people
>> from gmail were recently denied posting. So we had to relax them. The
>> problem with blacklists is that they're maintained by people who quickly
>> get addicted to the great power they have by being able to decide who is
>> allowed to send mail and who isn't allowed. It quickly turns a technical
>> tool into a political one.
>> 
>> I don't have a magic solution to this. The real point is that a mailing
>> list always comes with some spam and any mailbox also comes with some
>> spam anyway. So as long as the mailing list only adds a few percent of
>> spam to the one you already have, I really think it's not worth blocking
>> legitimate users to try to save this.
>> 
>> Willy
>> 
> 
> (Note: I'm replying to all, because I dont know who is legitimately
> subscribed to the list. Probably all of you are? in which case I am
> going to assume that your mail client should be set up to de-duplicate
> messages already)
> 
> How about a 4th "magic" solution? (And yes, this will involve some
> magic, specifically on the part of the mailing list) Allow for people
> brought in to a conversation to be automatically subscribed (so that
> way they dont lose messages if somebody neglects to do a "reply all")
> to that (and only to that) specific thread. No work at all necessary
> on their part (ie. no subscription and unsubscription). It'll involve
> tracking a bit more data (specifically adding specific recipients to
> specific mail threads). The only question is, how often does this
> happen (people get added to a conversation). And if this extra data
> proves to be a problem, it can always be expunged after some
> determined interval. Magic tracking! (just like sticky sessions, haha)
> 
> -jf
> 

Re: Spam

[Jeffrey 'jf' Lim]

On Mon, Apr 14, 2014 at 9:25 PM, Willy Tarreau  wrote:
> On Mon, Apr 14, 2014 at 09:03:44AM -0400, Patrick Hemmer wrote:
>> While I strongly disagree, I can respect your reasoning. But perhaps
>> there are solutions other than restricting non-subscribers. I can think
>> of these few without much thought:
>> 1) add grey listing (http://en.wikipedia.org/wiki/Greylisting).
>
> We already have some greylisting which is why we have "only" a little
> bit of spam.
>
>> 2) add a header indicating whether the sender is subscribed to the
>> mailing list. Then anyone who wants to remain on the list can add a
>> filter to auto-delete mail when the sender isn't on the list. I don't
>> know the numbers, but I'd bet the valid non-subscriber mail is rare.
>
> Among 2000 participants, we have 700 permanent subscribers, which means
> that other ones unsubscribe after a few exchanges. Some people (including
> myself) also have multiple addresses and will post from work or home
> using a different one while they don't want to be subscribed multiple
> times.
>
>> 3) Add a spamhaus IP blacklist. While I doubt this would block any
>> legitimate mail, it is possible. So I expect this to be met with the
>> same resistance as only allowing subscribers.
>
> We're currently using one such crappy BLs, which was the reason people
> from gmail were recently denied posting. So we had to relax them. The
> problem with blacklists is that they're maintained by people who quickly
> get addicted to the great power they have by being able to decide who is
> allowed to send mail and who isn't allowed. It quickly turns a technical
> tool into a political one.
>
> I don't have a magic solution to this. The real point is that a mailing
> list always comes with some spam and any mailbox also comes with some
> spam anyway. So as long as the mailing list only adds a few percent of
> spam to the one you already have, I really think it's not worth blocking
> legitimate users to try to save this.
>
> Willy
>

(Note: I'm replying to all, because I dont know who is legitimately
subscribed to the list. Probably all of you are? in which case I am
going to assume that your mail client should be set up to de-duplicate
messages already)

How about a 4th "magic" solution? (And yes, this will involve some
magic, specifically on the part of the mailing list) Allow for people
brought in to a conversation to be automatically subscribed (so that
way they dont lose messages if somebody neglects to do a "reply all")
to that (and only to that) specific thread. No work at all necessary
on their part (ie. no subscription and unsubscription). It'll involve
tracking a bit more data (specifically adding specific recipients to
specific mail threads). The only question is, how often does this
happen (people get added to a conversation). And if this extra data
proves to be a problem, it can always be expunged after some
determined interval. Magic tracking! (just like sticky sessions, haha)

-jf

Re: Spam

[Willy Tarreau]

On Mon, Apr 14, 2014 at 02:02:46PM +, Juan  Jimenez wrote:
> Like most people who subscribe, I do so because I
> want to follow the discussions on the product and have more than a passing
> interest in it, especially since the current dev version addresses things
> that are needed to be useful in the configuration we are supporting.
> Subscribe/Unsubscribe is a simple process in virtually all mailing lists
> now. Like I said, this is 2014?

Yes, and 2014 means what ? spam everywhere has become standard. OK.
And subscribing/unsubscribing is painful and impolite for people who are
CCed and try to respond and get rejected. It happened to me a few times
on other lists and I simply dropped the mail I tried to send because I
wasn't going to subscribe for this.

Also, we're in 2014. You're not forced to read the discussions via the
list, there are marc.info and gmane as well.

Willy

Re: Spam

[Juan Jimenez]

On 4/14/14, 8:30 AM, "Willy Tarreau"  wrote:


>On Fri, Apr 11, 2014 at 06:14:09PM -0700, Ian Scott wrote:
>> On 04/07/2014 07:47 AM, Juan Jimenez wrote:
>> >Is there a reason this list allows anyone to post messages? The amount
>>of
>> >spam on this list is astounding. This is 2014, folks. The methods to
>> >prevent this became good practice long, long ago.
>> 
>> I agree, this is pretty ridiculous. The list should be only open to
>> posting from subscribers.
>
>What is ridiculous are lists which send messages back to people who are
>brought to a conversation and which force them to subscribe before posting
>a response to kindly offer assistance to help someone.
>
>This list, as a number of other opensource projects lists, is open, which
>means that *nobody* is forced to subscribe to contribute. If you don't
>subscribe, you don't receive any spam.
>
>So I strongly urge you to unsubscribe to save 20 or so spams a week you
>can
>get here. I'm used to get something between 10 and 100 a day on other
>higher
>volume lists and it's not a problem, so surely dealing with 20 a week is
>OK.
> 
>Willy

Actually, no, it¹s not. Like most people who subscribe, I do so because I
want to follow the discussions on the product and have more than a passing
interest in it, especially since the current dev version addresses things
that are needed to be useful in the configuration we are supporting.
Subscribe/Unsubscribe is a simple process in virtually all mailing lists
now. Like I said, this is 2014Š

Juan

Re: use ipv6 for name resolution

[Willy Tarreau]

On Mon, Apr 14, 2014 at 02:46:09PM +0200, Nenad Merdanovic wrote:
> Something along the lines for commit message should be OK:
> 
> BUG/MINOR: Fix name lookup ordering when compiled with USE_GETADDRINFO
> 
> When compiled with USE_GETADDRINFO, make sure we use getaddrinfo(3) to
> perform name lookups. On default dual-stack setups this will change the
> behavior of using IPv6 first. Global configuration option
> 'nogetaddrinfo' can be used to revert to deprecated gethostbyname(3).

OK, pushed with this.

> Compiles fine here with 0e82b92a97, although the patch doesn't apply
> cleanly because the doc/configuration.txt is already updated in that
> commit (not sure why though):

I accidentely merged it with the other patch fixing typos. That's exactly
why I prefer to always have git patches as much as possible, as they save
me from doing manual git-add and avoid these mistakes.

It's not big deal this time though.

Thanks,
Willy

Re: Spam

[Willy Tarreau]

On Mon, Apr 14, 2014 at 09:03:44AM -0400, Patrick Hemmer wrote:
> While I strongly disagree, I can respect your reasoning. But perhaps
> there are solutions other than restricting non-subscribers. I can think
> of these few without much thought:
> 1) add grey listing (http://en.wikipedia.org/wiki/Greylisting).

We already have some greylisting which is why we have "only" a little
bit of spam.

> 2) add a header indicating whether the sender is subscribed to the
> mailing list. Then anyone who wants to remain on the list can add a
> filter to auto-delete mail when the sender isn't on the list. I don't
> know the numbers, but I'd bet the valid non-subscriber mail is rare.

Among 2000 participants, we have 700 permanent subscribers, which means
that other ones unsubscribe after a few exchanges. Some people (including
myself) also have multiple addresses and will post from work or home
using a different one while they don't want to be subscribed multiple
times.

> 3) Add a spamhaus IP blacklist. While I doubt this would block any
> legitimate mail, it is possible. So I expect this to be met with the
> same resistance as only allowing subscribers.

We're currently using one such crappy BLs, which was the reason people
from gmail were recently denied posting. So we had to relax them. The
problem with blacklists is that they're maintained by people who quickly
get addicted to the great power they have by being able to decide who is
allowed to send mail and who isn't allowed. It quickly turns a technical
tool into a political one.

I don't have a magic solution to this. The real point is that a mailing
list always comes with some spam and any mailbox also comes with some
spam anyway. So as long as the mailing list only adds a few percent of
spam to the one you already have, I really think it's not worth blocking
legitimate users to try to save this.

Willy

Re: Spam

[Patrick Hemmer]

*From: *Willy Tarreau 
*Sent: * 2014-04-14 08:30:39 E
*To: *Ian Scott 
*CC: *haproxy@formilux.org
*Subject: *Re: Spam

> On Fri, Apr 11, 2014 at 06:14:09PM -0700, Ian Scott wrote:
>> On 04/07/2014 07:47 AM, Juan Jimenez wrote:
>>> Is there a reason this list allows anyone to post messages? The amount of
>>> spam on this list is astounding. This is 2014, folks. The methods to
>>> prevent this became good practice long, long ago.
>> I agree, this is pretty ridiculous. The list should be only open to 
>> posting from subscribers.
> What is ridiculous are lists which send messages back to people who are
> brought to a conversation and which force them to subscribe before posting
> a response to kindly offer assistance to help someone.
>
> This list, as a number of other opensource projects lists, is open, which
> means that *nobody* is forced to subscribe to contribute. If you don't
> subscribe, you don't receive any spam.
>
> So I strongly urge you to unsubscribe to save 20 or so spams a week you can
> get here. I'm used to get something between 10 and 100 a day on other higher
> volume lists and it's not a problem, so surely dealing with 20 a week is OK.
>  
> Willy

While I strongly disagree, I can respect your reasoning. But perhaps
there are solutions other than restricting non-subscribers. I can think
of these few without much thought:
1) add grey listing (http://en.wikipedia.org/wiki/Greylisting).
2) add a header indicating whether the sender is subscribed to the
mailing list. Then anyone who wants to remain on the list can add a
filter to auto-delete mail when the sender isn't on the list. I don't
know the numbers, but I'd bet the valid non-subscriber mail is rare.
3) Add a spamhaus IP blacklist. While I doubt this would block any
legitimate mail, it is possible. So I expect this to be met with the
same resistance as only allowing subscribers.

Anyway, that's all I'm going to say on this subject.


-Patrick

RE: use ipv6 for name resolution

[Lukas Tribus]

Hi,


>>> Fails for me when compiling with USE_GETADDRINFO:
>>> src/standard.c: In function ?str2ip?:
>>> src/standard.c:554:6: error: ?global? undeclared (first use in this 
>>> function)
>>> src/standard.c:554:6: note: each undeclared identifier is reported only 
>>> once for each function it appears in
>>> src/standard.c:554:28: error: ?GTUNE_USE_GAI? undeclared (first use in this 
>>> function)
>>> make: *** [src/standard.o] Error 1
>>
>> Needs to include 
>
> Compiles fine here with 0e82b92a97, although the patch doesn't apply
> cleanly because the doc/configuration.txt is already updated in that
> commit (not sure why though):

Apologies, I was at dev22 instead of master by mistake, I confirm it works.



Regards,

Lukas

  

Re: use ipv6 for name resolution

[Nenad Merdanovic]

Hello,

On 04/14/2014 02:32 PM, Willy Tarreau wrote:
> Hi Lukas,
> 
> On Mon, Apr 14, 2014 at 02:22:33PM +0200, Lukas Tribus wrote:
>> Hi,
>>
>>
>>> Hi Nenad,
>>>
>>> On Mon, Apr 14, 2014 at 12:39:23PM +0200, Nenad Merdanovic wrote:
 I have attached another patch for review. I have removed some
 ifdef/else/endif code and it looks to be more readable for me this way
 (and in line how it was before this change). If you still prefer to have
 an ifdef around the whole function body, let me know, I'll rewrite it.
>>>
>>> At first glance it looks fine this way.
>>>
 I was also not 100% sure about using GTUNE_USE flags, but seems like the
 right way to do (as long as we don't see those flags as performance
 tuning related only). Let me know if this is something you are willing
 to merge and I'll write a proper commit message.
>>>
>>> You used it exactly the way it's supposed to be used, that's perfect.
>>>
>>> Unless someone else steps up with a comment, I agree with your patch.
>>> Please go forward by providing the commit message, I'll happily merge it.

Something along the lines for commit message should be OK:

BUG/MINOR: Fix name lookup ordering when compiled with USE_GETADDRINFO

When compiled with USE_GETADDRINFO, make sure we use getaddrinfo(3) to
perform name lookups. On default dual-stack setups this will change the
behavior of using IPv6 first. Global configuration option
'nogetaddrinfo' can be used to revert to deprecated gethostbyname(3).


>>
>>
>> Fails for me when compiling with USE_GETADDRINFO:
>> src/standard.c: In function ?str2ip?:
>> src/standard.c:554:6: error: ?global? undeclared (first use in this function)
>> src/standard.c:554:6: note: each undeclared identifier is reported only once 
>> for each function it appears in
>> src/standard.c:554:28: error: ?GTUNE_USE_GAI? undeclared (first use in this 
>> function)
>> make: *** [src/standard.o] Error 1
> 
> Needs to include 

Compiles fine here with 0e82b92a97, although the patch doesn't apply
cleanly because the doc/configuration.txt is already updated in that
commit (not sure why though):

+nogetaddrinfo
+  Disables the use of getaddrinfo(3) for name resolving. It is
equivalent to
+  the command line argument "-dG". Deprecated gethostbyname(3) will be
used.
+

> 
>> Also, should we by default enable USE_GETADDRINFO on selected targets
>> like linux2628, openbsd, osx, etc? Or maybe as a separate commit to
>> allow better bisectability?
> 
> A second commit would be preferred for exactly the reason you mentionned.
> 
> Willy
> 

Regards,
-- 
Nenad Merdanovic | PGP: 0x423edcb2 | Web: http://nimzo.info
Linkedin: http://www.linkedin.com/in/nenadmerdanovic

Re: use ipv6 for name resolution

[Willy Tarreau]

Hi Lukas,

On Mon, Apr 14, 2014 at 02:22:33PM +0200, Lukas Tribus wrote:
> Hi,
> 
> 
> > Hi Nenad,
> >
> > On Mon, Apr 14, 2014 at 12:39:23PM +0200, Nenad Merdanovic wrote:
> >> I have attached another patch for review. I have removed some
> >> ifdef/else/endif code and it looks to be more readable for me this way
> >> (and in line how it was before this change). If you still prefer to have
> >> an ifdef around the whole function body, let me know, I'll rewrite it.
> >
> > At first glance it looks fine this way.
> >
> >> I was also not 100% sure about using GTUNE_USE flags, but seems like the
> >> right way to do (as long as we don't see those flags as performance
> >> tuning related only). Let me know if this is something you are willing
> >> to merge and I'll write a proper commit message.
> >
> > You used it exactly the way it's supposed to be used, that's perfect.
> >
> > Unless someone else steps up with a comment, I agree with your patch.
> > Please go forward by providing the commit message, I'll happily merge it.
> 
> 
> Fails for me when compiling with USE_GETADDRINFO:
> src/standard.c: In function ?str2ip?:
> src/standard.c:554:6: error: ?global? undeclared (first use in this function)
> src/standard.c:554:6: note: each undeclared identifier is reported only once 
> for each function it appears in
> src/standard.c:554:28: error: ?GTUNE_USE_GAI? undeclared (first use in this 
> function)
> make: *** [src/standard.o] Error 1

Needs to include 

> Also, should we by default enable USE_GETADDRINFO on selected targets
> like linux2628, openbsd, osx, etc? Or maybe as a separate commit to
> allow better bisectability?

A second commit would be preferred for exactly the reason you mentionned.

Willy

Re: Spam

[Willy Tarreau]

On Fri, Apr 11, 2014 at 06:14:09PM -0700, Ian Scott wrote:
> On 04/07/2014 07:47 AM, Juan Jimenez wrote:
> >Is there a reason this list allows anyone to post messages? The amount of
> >spam on this list is astounding. This is 2014, folks. The methods to
> >prevent this became good practice long, long ago.
> 
> I agree, this is pretty ridiculous. The list should be only open to 
> posting from subscribers.

What is ridiculous are lists which send messages back to people who are
brought to a conversation and which force them to subscribe before posting
a response to kindly offer assistance to help someone.

This list, as a number of other opensource projects lists, is open, which
means that *nobody* is forced to subscribe to contribute. If you don't
subscribe, you don't receive any spam.

So I strongly urge you to unsubscribe to save 20 or so spams a week you can
get here. I'm used to get something between 10 and 100 a day on other higher
volume lists and it's not a problem, so surely dealing with 20 a week is OK.
 
Willy

RE: use ipv6 for name resolution

[Lukas Tribus]

Hi,


> Hi Nenad,
>
> On Mon, Apr 14, 2014 at 12:39:23PM +0200, Nenad Merdanovic wrote:
>> I have attached another patch for review. I have removed some
>> ifdef/else/endif code and it looks to be more readable for me this way
>> (and in line how it was before this change). If you still prefer to have
>> an ifdef around the whole function body, let me know, I'll rewrite it.
>
> At first glance it looks fine this way.
>
>> I was also not 100% sure about using GTUNE_USE flags, but seems like the
>> right way to do (as long as we don't see those flags as performance
>> tuning related only). Let me know if this is something you are willing
>> to merge and I'll write a proper commit message.
>
> You used it exactly the way it's supposed to be used, that's perfect.
>
> Unless someone else steps up with a comment, I agree with your patch.
> Please go forward by providing the commit message, I'll happily merge it.


Fails for me when compiling with USE_GETADDRINFO:
src/standard.c: In function ‘str2ip’:
src/standard.c:554:6: error: ‘global’ undeclared (first use in this function)
src/standard.c:554:6: note: each undeclared identifier is reported only once 
for each function it appears in
src/standard.c:554:28: error: ‘GTUNE_USE_GAI’ undeclared (first use in this 
function)
make: *** [src/standard.o] Error 1



Also, should we by default enable USE_GETADDRINFO on selected targets
like linux2628, openbsd, osx, etc? Or maybe as a separate commit to
allow better bisectability?




Regards,

Lukas

  

Re: haproxy 1.4.xx - 1.5dev22

[Willy Tarreau]

Hello,

please, when you send a private e-mail and send it again on the ML, do
at least CC the person you send it to first, it avoids duplicate responses
which waste time for everyone.

On Sun, Apr 13, 2014 at 04:18:49AM +0300, infin...@nkm.lt wrote:
> Hello.
> 
> I'm new to haproxy, and even to linux. However if you don't mind i would
> like to know some things.
> 
> haproxy version 1.4.25
> 
> In this version when i setup haproxy example of settings:
> 
> listen mysvr *:30001
> mode tcp
> server svr1 123.123.123.123:30001 check
> 
> In my running program on port 30001, i don't see any checks and @
> statistics page i see its online, if I close running program on statistics
> page its immediately change status to DOWN.
> ss: http://i.share.pho.to/fcbb9a67_o.png
> Everything is ok here.
> 
> 
> haproxy version 1.5dev22
> 
> In this version with same configuration settings:
> 
> listen mysvr *:30001
> mode tcp
> server svr1 123.123.123.123:30001 check
> 
> On my running program which is on port 30001, i see "connection checks"
> every second.
> ss: http://i.share.pho.to/0531397d_o.png
> Yes, its possible to set inter with value for check, but then we get
> statistics updated as example every 15min only or so.
> 
> My question is, can we set somehow "quiet" checks of port 30001 with
> 1.5dev22 as in 1.4 versions?

So as indicated in yesterdays email, it's caused by a reg in dev22 related
to tcp-check connect which causes each tcp check to wait for the timeout
before closing, thus the server receives the ACK. In all other versions,
we manage to send a TCP RST before the ACK so the server does not know
there was a pending connection request.

Willy

Re: suppress reqrep / use_backend warning

[Willy Tarreau]

Hi Patrick,

On Sun, Apr 13, 2014 at 11:02:50PM -0400, Patrick Hemmer wrote:
(...)
> Hadn't really thought about the best way to solve it until now. I like
> the per-line suppression more than the @BEGIN/@END one. The only other
> way I can think of doing this is by having a config directive such as:
> ignore-warnings reqrep_use_backend
> Which would suppress all occurrences of that specific warning. But then
> the warning message itself would need some sort of identifier on it so
> we knew what argument to pass to 'ignore-warnings'
> 
> I'll play with the patch tomorrow, see how manageable it is.
> 
> But really, this is a trivial matter. I'd be OK with whatever is decided.

I think that what would be the sanest approach would be to hide the warnings
using -q or "quiet" and only have a summary at the end such as :

264 warnings silenced.

That way if you're used to a certain number, your attention can still be
caught by a growing number.

However to be clear, I really don't want to remove the warning you're hitting
because people *are* writing odd configs whenever such warnings are not
emitted. We need to add another one which is missing for http-req vs use_backend
BTW. I've see a series of wrong configs in a row, all caused by the absence of
this warning.

Regards,
Willy

Re: [PATCH] config typos.

[Willy Tarreau]

Hello Jarno,

On Sat, Apr 12, 2014 at 06:22:19PM +0300, Jarno Huuskonen wrote:
> Hello,
> 
> Here's a small patch that fixes a few typos in
> configuration.txt (and one in haproxy.1).
> 
> Patch is for haproxy-ss-20140401 but should apply to
> haproxy-ss-20140411.

Great, much appreciated, thank you!
I've applied it now.

Willy

Re: use ipv6 for name resolution

[Willy Tarreau]

Hi Nenad,

On Mon, Apr 14, 2014 at 12:39:23PM +0200, Nenad Merdanovic wrote:
> I have attached another patch for review. I have removed some
> ifdef/else/endif code and it looks to be more readable for me this way
> (and in line how it was before this change). If you still prefer to have
> an ifdef around the whole function body, let me know, I'll rewrite it.

At first glance it looks fine this way.

> I was also not 100% sure about using GTUNE_USE flags, but seems like the
> right way to do (as long as we don't see those flags as performance
> tuning related only). Let me know if this is something you are willing
> to merge and I'll write a proper commit message.

You used it exactly the way it's supposed to be used, that's perfect.

Unless someone else steps up with a comment, I agree with your patch.
Please go forward by providing the commit message, I'll happily merge it.

Thanks,
Willy

Re: use ipv6 for name resolution

[Nenad Merdanovic]

Hello,

>> Let me see if we are on the same page:
>> - remove the USE flag USE_GETADDRINFO and use gai() by default
> 
> No, we cannot remove them as some supported systems don't provide gai().
> However we can put it by default in the implicit options for the systems
> which are known for supporting it well.
> 
>> - implement a global config option to disable gai()
> 
> yes.
> 
>> - gai(), if not disabled, would take precedence over ghbn() (Nenad's patch)
> 
> yes.
> 
>> This way:
>> - a user can always force IPv4 by prefixing the server with ipv4@
>> - a user can disable gai() with the global config option
> 
> Yes to both.
> 
>> - the behavior doesn't depend on USE flags (which the user may not be able
>>   change)
> 
> The behaviour does not depend on the flag *alone*, but for compatibility
> reasons we'll keep it.
> 
>> This way we are moving forward (ghbn() -> gai()), while we can still restore
>> the old behavior via configuration and we don't depend on USE flags to do so.
>>
>> I like this and I fully agree with this approach.
> 
> OK great!
> 
> Willy
> 
> 

I have attached another patch for review. I have removed some
ifdef/else/endif code and it looks to be more readable for me this way
(and in line how it was before this change). If you still prefer to have
an ifdef around the whole function body, let me know, I'll rewrite it.

I was also not 100% sure about using GTUNE_USE flags, but seems like the
right way to do (as long as we don't see those flags as performance
tuning related only). Let me know if this is something you are willing
to merge and I'll write a proper commit message.

Regards,
-- 
Nenad Merdanovic | PGP: 0x423edcb2 | Web: http://nimzo.info
Linkedin: http://www.linkedin.com/in/nenadmerdanovic
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 5873fc3..93f57cc 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -475,6 +475,7 @@ The following keywords are supported in the "global" section :
- nokqueue
- nopoll
- nosplice
+   - nogetaddrinfo
- spread-checks
- tune.bufsize
- tune.chksize
@@ -826,6 +827,10 @@ nosplice
   case of doubt. See also "option splice-auto", "option splice-request" and
   "option splice-response".
 
+nogetaddrinfo
+  Disables the use of getaddrinfo(3) for name resolving. It is equivalent to
+  the command line argument "-dG". Deprecated gethostbyname(3) will be used.
+
 spread-checks <0..50, in percent>
   Sometimes it is desirable to avoid sending agent and health checks to
   servers at exact intervals, for instance when many logical servers are
diff --git a/include/types/global.h b/include/types/global.h
index 669ec23..022c1b5 100644
--- a/include/types/global.h
+++ b/include/types/global.h
@@ -57,6 +57,7 @@
 #define GTUNE_USE_KQUEUE (1<<3)
 /* platform-specific options */
 #define GTUNE_USE_SPLICE (1<<4)
+#define GTUNE_USE_GAI(1<<5)
 
 /* Access level for a stats socket */
 #define ACCESS_LVL_NONE 0
diff --git a/src/cfgparse.c b/src/cfgparse.c
index 344bde1..a348029 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -506,6 +506,9 @@ int cfg_parse_global(const char *file, int linenum, char **args, int kwm)
 	else if (!strcmp(args[0], "nosplice")) {
 		global.tune.options &= ~GTUNE_USE_SPLICE;
 	}
+	else if (!strcmp(args[0], "nogetaddrinfo")) {
+		global.tune.options &= ~GTUNE_USE_GAI;
+	}
 	else if (!strcmp(args[0], "quiet")) {
 		global.mode |= MODE_QUIET;
 	}
diff --git a/src/haproxy.c b/src/haproxy.c
index fb8c8a1..67798b4 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -385,6 +385,9 @@ void usage(char *name)
 #if defined(CONFIG_HAP_LINUX_SPLICE)
 		"-dS disables splice usage (broken on old kernels)\n"
 #endif
+#if defined(USE_GETADDRINFO)
+		"-dG disables getaddrinfo() usage\n"
+#endif
 		"-dV disables SSL verify on servers side\n"
 		"-sf/-st [pid ]* finishes/terminates old pids. Must be last arguments.\n"
 		"\n",
@@ -553,6 +556,9 @@ void init(int argc, char **argv)
 #if defined(CONFIG_HAP_LINUX_SPLICE)
 	global.tune.options |= GTUNE_USE_SPLICE;
 #endif
+#if defined(USE_GETADDRINFO)
+	global.tune.options |= GTUNE_USE_GAI;
+#endif
 
 	pid = getpid();
 	progname = *argv;
@@ -592,6 +598,10 @@ void init(int argc, char **argv)
 			else if (*flag == 'd' && flag[1] == 'S')
 global.tune.options &= ~GTUNE_USE_SPLICE;
 #endif
+#if defined(USE_GETADDRINFO)
+			else if (*flag == 'd' && flag[1] == 'G')
+global.tune.options &= ~GTUNE_USE_GAI;
+#endif
 			else if (*flag == 'd' && flag[1] == 'V')
 global.ssl_server_verify = SSL_SERVER_VERIFY_NONE;
 			else if (*flag == 'V')
diff --git a/src/standard.c b/src/standard.c
index 569ecaa..6669c32 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -552,25 +552,8 @@ static struct sockaddr_storage *str2ip(const char *str, struct sockaddr_storage
 		return sa;
 	}
 
-	/* try to resolve an IPv4/IPv6 hostname */
-	he = gethostbyname(str);
-	if (he) {
-		if (!sa->ss_family || sa->ss_family == AF_UNS

RE: Stick on SSL Session ID (ssl_session_id)

[Lukas Tribus]

Hi Volker,


> Sometimes, the Serverhello/Clienthello contains an empty session ID.
> Is it possible that HAProxy has problems with this behaviour?

If there is no session id, HAproxy can't fix the session to a server.



> Any idea?

There is a good chance that your backend supports both SSL session
resumption *and* TLS tickets. In case TLS tickets hops in, SSL session
will not be used and HAProxy therefor can't stick to the correct
server.

Disabling TLS Tickets on your backend could fix that particular issue.




Regards,

Lukas

  

Stick on SSL Session ID (ssl_session_id)

[Volker Dormeyer]

Dear All,

I've a question related to stickyness based on the SSL session ID.

I am using HAProxy 1.5-dev22 with the following configuration:


frontend fe_test_ssl
bind 10.1.1.10:443
default_backend be_test_ssl

backend be_test_ssl
mode tcp
balance roundrobin

stick-table type binary len 32 size 30k expire 30m

acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2

tcp-request inspect-delay 5s
tcp-request content accept if clienthello
tcp-response content accept if serverhello

stick on payload_lv(43,1) if clienthello
stick store-response payload_lv(43,1) if serverhello

server myserver1 10.10.10.1:443
server myserver2 10.10.10.2:443


SSL-Offloading ist not being used in this environment!

Problem: It looks like the configuration above is not working
reliably. According to the HAProxy Log and Browser behaviour,
the session is often switched to the second server, which
shouldn't be the case. I did some dumps using ssldump to
figure out, what happens.

Snippet from ssldump:


session_id[0]=

session_id[32]=
  32 33 37 38 38 34 33 32 32 68 6a 33 34 68 6a 32
  6b 33 6a 68 32 34 68 33 34 6a 33 68 a1 2c e4 03

session_id[0]=

session_id[32]=
  32 33 37 38 38 34 33 32 32 68 6a 33 34 68 6a 32
  6b 33 6a 68 32 34 68 33 34 6a 33 68 a1 2c e4 03

session_id[32]=
  32 33 37 38 38 34 33 32 32 68 6a 33 34 68 6a 32
  6b 33 6a 68 32 34 68 33 34 6a 33 68 a1 2c e4 03

session_id[32]=
  32 33 37 38 38 34 33 32 32 68 6a 33 34 68 6a 32
  6b 33 6a 68 32 34 68 33 34 6a 33 68 a1 2c e4 03


Sometimes, the Serverhello/Clienthello contains an empty session ID.
Is it possible that HAProxy has problems with this behaviour?

Any idea?

Thanks and Best Regards,
Volker 


-- 
  Volker Dormeyer

RFC: removal of bsd and osx Makefiles

[Lukas Tribus]

Hi list,


this is to request comments regarding the removal of bsd and osx Makfiles.

Its was proposed by Willy Tarreau, the reason are:
- osx and bsd Makefiles don't support USE flag, so they can't be used if
  SSL, ZLIB and other specific features requiring USE flags are needed
- it can be confusing for the users having multiple Makefiles
- GNU make (gmake) is commonly used noawdays
- regressions in bsd and osx Makefiles are reported very late (also see [1])

I agree with Willy's proposal.



>>> I'm wondering whether we should not simply remove these files at all,
>>> as it seems that everyone is using gmake nowadays, so their presence
>>> is more confusing than anything else, and the occasional breakage they
>>> cause is always reported very late.
>>
>> Yes, its also a additional maintenance burden plus those makefiles lack
>> support of the USE flags, so they become less and less useful anyway.
>
> Agreed. Anyone has any objection against removing these files which do
> not even offer the option to enable SSL ?

Any comments appreciated.





Regards,

Lukas


[1] 
http://haproxy.1wt.eu/git?p=haproxy.git;a=commit;h=01193d6efbb731dd83eeb9addc14cecb16c431af