RE: Query regarding extracting ssl hello sni.

Hi, I would suggest that it will not harm even if you relax the check for client hello too as the old client can using SSL 3.0 is still supported and its according to RFC I disagree. SNI is documented as a TLS extension and unsupported in SSLv3. RFC3546 and RFC6066 are the relevant RFCs, not

use ipv6 for name resolution

sorry for what is probably a pretty noob question, but could anyone tell me why haproxy resolves the hostnames in my config to ipv4 addresses, and not ipv6? If I run a tcpdump on port 53 during a haproxy restart I can see that only the A records are being queried. However, if I curl one of the

Re: use ipv6 for name resolution

This is because haproxy does not support IPv6 for backends. It makes no sense to query those addresses only to not use them afterwards. On Fri, 2014-04-11 at 11:15 +0200, Manuel Bauer wrote: sorry for what is probably a pretty noob question, but could anyone tell me why haproxy resolves the

Re: use ipv6 for name resolution

Hello, On 04/11/2014 11:15 AM, Manuel Bauer wrote: sorry for what is probably a pretty noob question, but could anyone tell me why haproxy resolves the hostnames in my config to ipv4 addresses, and not ipv6? If I run a tcpdump on port 53 during a haproxy restart I can see that only the A

Re: use ipv6 for name resolution

Good idea, but that seems to work only with ip addresses, and not hostnames. If I try it haproxy complains about an error in its config and refuses to start. On Fri, 11 Apr 2014 12:04:40 +0200, Nenad Merdanovic ni...@nimzo.info wrote: Hello, On 04/11/2014 11:15 AM, Manuel Bauer wrote:

Re: Query regarding extracting ssl hello sni.

I too agree with your first comment relax only the check for record layer version as SNI is extensions for TLS protocols. I think the next version may or may not contain the same client hello format if it allows i don't have any issues if it doesn't allows then the code may crash or it may return

RE: Query regarding extracting ssl hello sni.

Hi, I think the next version may or may not contain the same client hello format if it allows i don't have any issues if it doesn't allows then the code may crash or it may return bad value for SNI. I just suggested it for safety reasons its just my input. If HAproxy would crash, we

Re: Query regarding extracting ssl hello sni.

Ok fine you can be forward compatible but i still don't agree its my personal opinion if I don't know what the packet format for next version why should I support it. But this was not the major issue for what i started the discussion. I think the major is relaxing the record layer check to SSLv3

Re: Query regarding extracting ssl hello sni.

On Fri, Apr 11, 2014 at 04:57:17PM +0530, Pravin Tatti wrote: Ok fine you can be forward compatible but i still don't agree its my personal opinion if I don't know what the packet format for next version why should I support it. But this was not the major issue for what i started the

RE: Query regarding extracting ssl hello sni.

Hi, Ok fine you can be forward compatible but i still don't agree its my  personal opinion if I don't know what the packet format for next  version why should I support it. Because we are talking about a industry standard with a huge user base and it is very likely that next version will be

Re: use ipv6 for name resolution

Hello, On 04/11/2014 12:23 PM, Manuel Bauer wrote: Good idea, but that seems to work only with ip addresses, and not hostnames. If I try it haproxy complains about an error in its config and refuses to start. On Fri, 11 Apr 2014 12:04:40 +0200, Nenad Merdanovic ni...@nimzo.info wrote:

Re: use ipv6 for name resolution

Hi Nenad, On Fri, Apr 11, 2014 at 02:09:09PM +0200, Nenad Merdanovic wrote: Why are we using gethostbyname() first if USE_GETADDRINFO is enabled? Probably only because that's what we used to do for over a decade in fact. Getaddrinfo() used to work very badly on a large number of platforms,

Re: haproxy mis-reporting layer 4 checks

Hi Patrick, On Thu, Apr 10, 2014 at 02:17:02PM -0400, Patrick Hemmer wrote: I've brought up this bug before (http://marc.info/?l=haproxym=139312718801838), but it seems to not have gotten any attention, so I'm raising it again. There is an issue with haproxy mis-reporting layer 4 checks.

RE: use ipv6 for name resolution

Hi, On Fri, Apr 11, 2014 at 02:09:09PM +0200, Nenad Merdanovic wrote: Why are we using gethostbyname() first if USE_GETADDRINFO is enabled? Probably only because that's what we used to do for over a decade in fact. Getaddrinfo() used to work very badly on a large number of platforms,

Re: haproxy mis-reporting layer 4 checks

*From: *Willy Tarreau w...@1wt.eu *Sent: * 2014-04-11 08:29:15 E *To: *Patrick Hemmer hapr...@stormcloud9.net *CC: *haproxy@formilux.org *Subject: *Re: haproxy mis-reporting layer 4 checks Hi Patrick, On Thu, Apr 10,

Re: use ipv6 for name resolution

Hi Lukas, On Fri, Apr 11, 2014 at 02:43:47PM +0200, Lukas Tribus wrote: Hi, On Fri, Apr 11, 2014 at 02:09:09PM +0200, Nenad Merdanovic wrote: Why are we using gethostbyname() first if USE_GETADDRINFO is enabled? Probably only because that's what we used to do for over a decade in

RE: use ipv6 for name resolution

FYI, with getaddrinfo() - with Nenad's patch - against a dual-stacked host and without IPv6 connectivity leads to additional syscalls in this case: connect(4, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, 2a03:2880:f010:900:face:b00c:0:1, sin6_addr), sin6_flowinfo=0,

Re: haproxy mis-reporting layer 4 checks

On Fri, Apr 11, 2014 at 08:53:17AM -0400, Patrick Hemmer wrote: *From: *Willy Tarreau w...@1wt.eu *Sent: * 2014-04-11 08:29:15 E *To: *Patrick Hemmer hapr...@stormcloud9.net *CC: *haproxy@formilux.org *Subject: *Re:

Re: use ipv6 for name resolution

On Fri, Apr 11, 2014 at 02:55:20PM +0200, Martijn Otto wrote: FYI, with getaddrinfo() - with Nenad's patch - against a dual-stacked host and without IPv6 connectivity leads to additional syscalls in this case: connect(4, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,

RE: Query regarding extracting ssl hello sni.

Hi, It's not a matter of opinion but specification. If the packet format is specified as being exclusively for 3.0..3.3, then we should only match this. If it's specified as part of TLS for which only versions 3.0 to 3.3 are currently defined, then we must apply the default rule specified

haproxy HTML documentation

Hi all, I took some time this week to make changes to the HTML documentation. One important thing concerns the links to it : now you can find a documentation coming from the snapshots (the previous behaviour) and for stable releases (the latest release tag). Stable releases replaces previous

Re: Query regarding extracting ssl hello sni.

Hi Lukas, On Fri, Apr 11, 2014 at 03:17:32PM +0200, Lukas Tribus wrote: Hi, It's not a matter of opinion but specification. If the packet format is specified as being exclusively for 3.0..3.3, then we should only match this. If it's specified as part of TLS for which only versions 3.0 to

RE: Query regarding extracting ssl hello sni.

Hi Willy, So in my opinion, since the protocol is designed to be backwards and forwards compatible, and uses minor version for newer extensions, there is no reason for limiting ourselves to TLSv1.2 for extensions that exist since 1.0 and will certainly continue to be supported by later

Re: haproxy HTML documentation

How contributed translation doc. a spanish? 2014-04-11 10:20 GMT-03:00 Cyril Bonté cyril.bo...@free.fr: Hi all, I took some time this week to make changes to the HTML documentation. One important thing concerns the links to it : now you can find a documentation coming from the snapshots

src_inc_gpc0 not working with IPv4 source and IPv6 stick-tables

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

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

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:

Re: use ipv6 for name resolution

Hello, On 04/11/2014 02:59 PM, Willy Tarreau wrote: On Fri, Apr 11, 2014 at 02:55:20PM +0200, Martijn Otto wrote: FYI, with getaddrinfo() - with Nenad's patch - against a dual-stacked host and without IPv6 connectivity leads to additional syscalls in this case: connect(4,

Re: use ipv6 for name resolution

Hi Nenad, On Fri, Apr 11, 2014 at 05:24:02PM +0200, Nenad Merdanovic wrote: connect(4, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, 2a03:2880:f010:900:face:b00c:0:1, sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable) connect(4,

How do I used the map feature in haproxy to build massive redirect tables

I think the subject covers it. I need to build a list of many 301 redirects within the same domain i.e. redirect /some_old_place to /some_new_place. We have lots of content the gets retired or replaced based on url. The quote from the current home page of haproxy states maps may be used to

Re: How do I used the map feature in haproxy to build massive redirect tables

Hi Matt, Le 11/04/2014 18:45, Matt Higgins a écrit : I think the subject covers it. I need to build a list of many 301 redirects within the same domain i.e. redirect /some_old_place to /some_new_place. We have lots of content the gets retired or replaced based on url. The quote from the

Re: How do I used the map feature in haproxy to build massive redirect tables

Hi again, Le 11/04/2014 21:30, Cyril Bonté a écrit : I see several issues : 1. In order to not break older configurations, redirect will not support dynamic values, http-request redirect does. 2. Avoid spaces between parameters (between map and hdr). 3. Parameters are declared in the wrong

Remportez le voyage de vos rêves en Thaïlande

Title: Le Globe Trotteur vous invite en Thaïlande Cliquez ici pour lire cet e-mail dans votre navigateur.

Re: Spam

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

Re: haproxy intermittently not connecting to backend

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