RE: SEGFAULT in in buffer_insert_line2

Hi Bernd, Willy, > Hello, > > im getting segfault, it happens on 1 of ~500 million requests that are > processed on haproxy 1.6.2-2 on debian wheezy and jessie (systems > updated, crash stayed). > > If you need more informations, let me know. > > Thank You. > > Trace: > (gdb) thread apply all bt

RE: SSLv2Hello is disabled

Hi, > I'll try to pack again the OpenSSL files (must work with rpm) from > original repository and will let you know. Thanks. Ok, but first try the other proposal (takes less time): >> Should I just add to haproxy.cfg the following? >> force-tlsv10 > > Yes, you can try: > > global > ss

RE: Get haproxy to listen only on the public IP

Hi Unkown User! > Is there any way to get haproxy to listen only on the public IP, other  > than by specifying the IP?  > I dont want this to listen on the loopback.  Use the interface keyword: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-interface Regards, Lukas

RE: SSLv2Hello is disabled

Hi Galit, > I want to emphasize that the following test succeeded: > > [root@proxy-au51 ~]# openssl s_client -connect 10.106.75.53:50443 -tls1 > > CONNECTED(0003)  Ok. > Built with OpenSSL version : OpenSSL 0.9.8b 04 May 2006 > Running on OpenSSL version : OpenSSL 0.9.8e-fips-rhel5 0

RE: SSLv2Hello is disabled

javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled  >>> You need to disable SSLv3 in haproxy  >>  >> We are talking about the SSLv2 hello format. Its not about SSLv2 >> or SSLv3, its about the hello format.  > Which can also be used by sslv3 clients hence my comment.  True, but disab

RE: haproxy doesn't get SIGUSR1

> I'm using service_loadbalancer from kubernetes > (https://github.com/kubernetes/contrib/tree/master/service-loadbalancer ) > . This program would re-spawn haproxy when it found a change of > upstream endpoints. > When service_loadbalancer starts, it runs haproxy -sf $(cat pidfile) > several

RE: SSLv2Hello is disabled

> On 02/12/2015 12:41 AM, "Cohen Galit" > mailto:galit.co...@xura.com>> wrote: > > > > Hello, > > > > > > > > When HAProxy 1.5.9 is trying to sample our servers with this > configuration: tcp-check connect port 50443 ssl > > > > > > > > Our servers returns an error: > > > > > > >

RE: Owncloud through Haproxy makes upload not possible

> No, I have checked both lo0 and lo1 (I have lo1 set up for jails). Can you try outside of the jail? Somehow it must be possible to tcpdump this traffic. Lukas

RE: Owncloud through Haproxy makes upload not possible

> I'm not sure now, but it seems that packets routed in Haproxy are > somehow protected from dumping: > root@owncloud:~ # tcpdump -i em1 -vv port 80 > tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size > 10 bytes > ^C > 0 packets captured > 3774 packets received by filter > 0 pack

RE: Haproxy stats page returns 503 error

Hi Atul, > Hi, > > > using a browser to query the stats from haproxy, I'm facing a non > consistent behavior where about One time every 2 attempts I get a 503 > error. Please share the configuration so we can take a look. Regards, Lukas

[PATCH] BUG/MINOR: lua: don't force-sslv3 LUA's SSL socket

Sander Klein reported an error messages about SSLv3 not being supported on Debian 8, although he didn't force-sslv3. Vincent Bernat tracked this down to the LUA initialization, which actually does force-sslv3. This patch removes force-sslv3 from the LUA initialization, so the LUA SSL socket can a

RE: ssl parameters ignored

Hi, >> root@debianvm:/home/lukas/haproxy-1.6.2# haproxy -f /home/lukas/ssl.cfg -c >> [ALERT] 328/203304 (9873) : SSLv3 support requested but unavailable. >> Configuration file is valid >> root@debianvm:/home/lukas/haproxy-1.6.2# ./haproxy -f /home/lukas/ssl.cfg -c >> Configuration file is valid >

RE: ssl parameters ignored

Hi, >> I don't know. I got pre made packages from "http://haproxy.debian.net >> jessie-backports-1.6 main" maintained by Vincent Bernat if I'm correct. > > I think there's something wrong with that binary. I will try to reproduce > the problem with it. Confirmed. The 1.6.2 binary (haproxy) from

RE: Owncloud through Haproxy makes upload not possible

> I'm not sure why, but after doing haproxy -vv I now get kevent() in > truss output. I'm attaching another truss output. Ok, so thats not the problem, good. > While browsing the logs I've notices that besides the usual 200 > output, when uploading was > finished (unsuccessfully) I got the follo

RE: ssl parameters ignored

> On 2015-11-23 22:36, Lukas Tribus wrote: >> Are you sure that the executable was cleanly build (first "make clean", >> only then "make ...")? > > I don't know. I got pre made packages from "http://haproxy.debian.net > jessie-backports-1.6

RE: Owncloud through Haproxy makes upload not possible

Hi, >> Still seeing poll() in this trace. Are you sure nokqueue was removed >> in the configuration and haproxy was restarted? > Yes, I definitely did that. > [...] > Total: 3 (3 usable), will use kqueue. I don't get it. The trace doesn't match the configuration. When you start haproxy with th

RE: ssl parameters ignored

Hi, > When testing this config I get: > > [ALERT] 326/202736 (24201) : SSLv3 support requested but unavailable. > Configuration file is valid > > After testing with ssllabs I also noticed tlsv10 and tlsv11 were still > enabled. Downgrading to haproxy 1.5.14 removes the error when testing > the co

Re: ssl parameters ignored

Hi Sander, > When testing this config I get: > > [ALERT] 326/202736 (24201) : SSLv3 support requested but unavailable. > Configuration file is valid > > After testing with ssllabs I also noticed tlsv10 and tlsv11 were still > enabled. Downgrading to haproxy 1.5.14 removes the error when testing >

RE: Owncloud through Haproxy makes upload not possible

>> Ok, could you redo this trace with the "-d" option and >> without the nokqueue configuration. > Attached. Still seeing poll() in this trace. Are you sure nokqueue was removed in the configuration and haproxy was restarted? Please also provide the output of "haproxy -vv". Thanks, Lukas

RE: Owncloud through Haproxy makes upload not possible

Hi Piotr, >> - try nokqueue mode [1] > Didn't change anything. >> - try option http-no-delay [2] > Didn't change anything. Ok, please remove both options again. >> - check cpu usage (system and haproxy) while uploading > Load average is about 0.2-0.4 What we have to find out is if haproxy or

RE: Owncloud through Haproxy makes upload not possible

Hi Piotr, > Unfortunately, using 1.5.15 didn't change anything. a few things I would suggest to try/troubleshoot: - try nokqueue mode [1] - try option http-no-delay [2] - check cpu usage (system and haproxy) while uploading - truss ([3]) haproxy while uploading - tcpdump the frontend connection

RE: Connect() failed using unix sockets

>> >> So anybody know what resource "free ports" relates to in the unix >> domain socket case? Are there any other debug options to find out >> more about what is happening. > > I suspect the connect() call returns EAGAIN Digging some more, it looks like the kernel returns EAGAIN when the backlog

RE: Connect() failed using unix sockets

Hi Greg, > Connect() failed for backend frontend: no free ports. > Connect() failed for backend frontend: no free ports. > Connect() failed for backend frontend: no free ports. > Connect() failed for backend frontend: no free ports. > Connect() failed for backend frontend: no free ports. >

RE: [SPAM] Re: CPU 100% when waiting for the client timeout

> I think the right way to upgrade kernel with ubuntu, is: > > apt-get update && apt-get dist-upgrade Exactly, apt may hold back kernel upgrades otherwise. Lukas

RE: CPU 100% when waiting for the client timeout

> Hi Willy,  >  >> This one seems to have missed 3 years of bugfixes  > I've just done a "apt-get update && apt-get upgrade" successfully and  > reboot the machine this week. I think the OS is fresh enough, but I'll  > try to upgrade the kernal to a newer one. :-)  When you upgrade Ubuntu precise

RE: CPU 100% when waiting for the client timeout

>> # uname -a >> Linux WD-G0-SRP1 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC >> 2012 x86_64 x86_64 x86_64 GNU/Linux > > This one seems to have missed 3 years of bugfixes but anyway I don't see > how any kernel bug could make haproxy fail, and if it did we'd have to > find a workaround

RE: CPU 100% when waiting for the client timeout

Hello! > Sorry for send it again, I just forgot to provide the attachments. > > Affect verions: at least 1.5.15 and 1.6.2 > > Here is the related part in my configuration: > timeout client 15m # 客户端响应超时 > timeout client-fin 10s # 对客户端连接完成 TCP 4 次挥手超时 > timeout connect 5s # HAProxy 向后端 Ser

RE: Haproxy

> Howover, Can you send me some sample haproxy.cfg configuration file for  > Solaris 11. Sample configurations are already bundled with haproxy, check the folder examples/ Of course, the those configurations will not work out of the box for your specific requirements. You will have to understand

RE: Haproxy on solaris 11

> Hi Lukas, > > Sorry for that. I am not a operating system engineer. Than I suggest a commercial product with commercial support, like those from haproxy.com. I'm afraid its not possible to provide support for basic operating system tasks on this list (like understanding the presence or absence

RE: Haproxy on solaris 11

Hi Roja, > Hi, > > We need to install Haproxy on Solaris 11 sparc. > > I have downloaded from haproxy.org and taken example of sample > configuration file haproxy.cfg. > > I am getting the error while compiling the code.  You are not compiling the code. You are starting haproxy here. Th

RE: Fast reloads leave orphaned processes on systemd based systems

Hi Lukas, > When reloading haproxy too fast on EL7 (RedHat, CentOS) the system is > being filled with orphaned processes. > > I encountered this problem on CentOS 7 with > haproxy-1.5.4-4.el7_1.x86_64 but expect it to exist on all systems > using haproxy-systemd-wrapper not just those based on F

RE: Fast reloads leave orphaned processes on systemd based systems

Hi Lukas, > When reloading haproxy too fast on EL7 (RedHat, CentOS) the system is > being filled with orphaned processes. > > I encountered this problem on CentOS 7 with > haproxy-1.5.4-4.el7_1.x86_64 but expect it to exist on all systems > using haproxy-systemd-wrapper not just those based on F

RE: Haproxy 1.6 Ldap frontend/backend Segfault

> Hi > > I am testing out the new 1.6 Haproxy and everything works great except > when I try to use it for balancing LDAP traffic in mode tcp. It seems > to segfault after doing an initial connection. Below is the > information, please let me know if I can get you any other information. > Tha

RE: [PATCH v2] BUG/MINOR: acl: don't use record layer in req_ssl_ver

>> This should be backported to stable series, the req_ssl_ver keyword was >> first introduced in 1.3.16. > > Thanks Lukas, applied to 1.7, 1.6, 1.5 and 1.4. For 1.3 there might be > other patches pending so this one will get there at the same time. Great. I didn't really expect a 1.3 backport, I

[PATCH v2] BUG/MINOR: acl: don't use record layer in req_ssl_ver

The initial record layer version in a SSL handshake may be set to TLSv1.0 or similar for compatibility reasons, this is allowed as per RFC5246 Appendix E.1 [1]. Some implementations are Openssl [2] and NSS [3]. A related issue has been fixed some time ago in commit 57d229747 ("BUG/MINOR: acl: req_

RE: [PATCH] BUG/MINOR: acl: don't use record layer in req_ssl_ver

>> @@ -402,7 +402,7 @@ smp_fetch_req_ssl_ver(const struct arg *args, struct >> sample *smp, const char *kw >> if (bleft < 5) >> goto too_short; >> >> - version = (data[1] << 16) + data[2]; /* version: major, minor */ >> + version = (data[9] << 16) + data[10]; /* client hello version: major, >> mi

[PATCH] BUG/MINOR: acl: don't use record layer in req_ssl_ver

The initial record layer version in a SSL handshake may be set to TLSv1.0 or similar for compatibility reasons, this is allowed as per RFC5246 Appendix E.1 [1]. Some implementations are Openssl [2] and NSS [3]. A related issue has been fixed some time ago in commit 57d229747 ("BUG/MINOR: acl: req_

RE: Potential Bug

> I believe I may have discovered a bug in HAProxy 1.5.4 on CentOS 7.1, > installed via standard repositories. > > I don't want to go into debugging levels of detail here, but instead > will provide a synopsis in the hopes someone knows of a bug already or > can confirm it warrants further investig

RE: DNS resolution problem on 1.6.1-1ppa1~trusty

> I sent patches to Willy, and they have been integrated a few minutes ago. > You can git pull ; make clean ; make [...] Unless you use haproxy-1.6, in that case you have to wait for the backport and the git push, which has not happened yet. Lukas

RE: HA Proxy - packet capture functionality

> If Haproxy doesn't terminate the encryption there is nothing you can do in > any case. > If it does, you can listen for the unencrypted traffic going between haproxy > and the > backend using tcpdump with appropriate filtering as well. Also, if you for whatever reason need to decrypt the traff

RE: Wrong mode for SSL termination in config

>> Can somebody help us get more understanding as to what are the >> implications of adding wrong mode in config file and why this could >> cause a kernel panic if at all. > > There is no reason whatsoever that this should have caused a kernel > panic. zero. nada. None at all. Meaning: if haproxy

RE: Wrong mode for SSL termination in config

> We use HAProxy as our loadbalancer in our private cloud at Symantec. We > spin these HAProxy processes in a separate network namespaces. We had a > bug in our HAProxy config population script which was adding wrong mode > in frontend and backbend sections for SSL termination. The right mode

RE: [PATCH] MEDIUM: dns: Don't use the ANY query type

>> Baptiste, whats the current behavior when an empty response with >> NOERROR is received? >> >> Regards, >> >> Lukas > > > Hi, > > This is already handled when I detect response without NX code and no > response records (DNS_RESP_ANCOUNT_ZERO) or no response record > corresponding to the query (D

RE: no free ports && tcp_timestamps

> Hi, > > I checked kernel log and I can't find anything. How do I procede? Ask kernel folks. Or don't disable tcp_timestamps, a lot of important TCP features rely on it and those "security reasons" are ridiculous anyway. Uptime is not supposed to be a secret, if someone can attack you based on i

RE: no free ports && tcp_timestamps

> Hi Baptiste, > > I'll try your suggestiion, but I'd like to understand why if I enable > tcp_timestamp I have no problems and if I disable it, after few > minutes on the live system I get the problem. Clearly this is a kernel issue. Check your kernel logs/dmesg. Lukas

RE: Upgrade from 1.4 -> 1.6, any gotchas?

> On Wed, Oct 21, 2015 at 7:14 PM, SL wrote: >> I'll be doing an upgrade from 1.4 to 1.6 tomorrow. Just wondering if there >> are any changed defaults, breaking changes, anything like that? Or should >> my config work as before? > > Haproxy 1.5 changed the default connection mode if you use http.

RE: [PATCH] MEDIUM: dns: Don't use the ANY query type

Hi Robin, > Hey guys, > > Actually when you get an NXDOMAIN reply you can just stop resolving that > domain. Basically there are 2 types of "negative" replies in DNS: > > NODATA: basically this is when you don't get an error (NOERROR in dig), > but not the actual data you are looking for. You mig

RE: [PATCH] MEDIUM: dns: Don't use the ANY query type

> I don't know. I'm always only focused on the combination of user-visible > changes and risks of bugs (which are user-visible changes btw). So if we > can do it without breaking too much code, then it can be backported. What > we have now is something which is apparently insufficient to some users

RE: [PATCH] MEDIUM: dns: Don't use the ANY query type

Hi, >> A simple option in the resolvers section to instruct HAPoxy to not >> forgive on NX and failover to next family: >> option on-nx-try-next-family > > I personally find this confusing from the user's point of view. Agreed, we should have good and safe defaults, and address corner cases with

RE: [PATCH] MEDIUM: dns: Don't use the ANY query type

Hi, > Hi Andrew, > > There is a bug repeated twice in your code. > In both dns_reset_resolution() and trigger_resolution(), you use > "resolution->resolver_family_priority" before it is positioned. This > may lead to using the last resolution->resolver_family_priority, which > may be different tha

RE: 1.6.0 Error: Cannot Create Listening Socket for Frontend and Stats,Proxies

> Dear Willy, > > Thank you for your insights. As you advised, below is the output of > haproxy -f …cfg -db -V. Can you run this through strace (strace haproxy -f …cfg -db -V) and provide the output. Also, if you have the strace output of a successful startup of 1.5.14 for comparison, that would

RE: [PATCH] MEDIUM: dns: Don't use the ANY query type

> Hi Andrew, > > On Mon, Oct 19, 2015 at 05:39:58PM -0500, Andrew Hayworth wrote: >> The ANY query type is weird, and some resolvers don't 'do the legwork' >> of resolving useful things like CNAMEs. Given that upstream resolver >> behavior is not always under the control of the HAProxy administrato

RE: haproxy + ipsec -> general socket error

> when using ipsec on the backend side, this error pops up in the haproxy > log from time to time: > > Layer4 connection problem, info: "General socket error (No buffer space > available) > > > we have tried both strongswan and libreswan, error is still the same. > there is nothing strange

RE: responses from disabled servers

Hi David, > I just want to say first of all that haproxy is incredibly useful and > I've enjoyed working with it tremendously. Thank you! > > My question is if a server is disabled because of a failed http health > check and there are requests in flight, will the requests from the > disabled app

RE: SIGUSR1 soft stop does not send "Connection: close"

Hi, >> If the session is transferring HTTP body between client and backend server, >> we >> can't insert HTTP headers either. If you are waiting for the next request >> in that particular session, why wouldn't we just close it after the HTTP body >> has been transfered? > > That would be fine, do

RE: SIGUSR1 soft stop does not send "Connection: close"

> On Thu, Oct 15, 2015 at 12:26 PM, Lukas Tribus wrote: >> What request/response, aren't we talking about an idle session here? > > No, I am concerned with a non idle persistent session. When specifically would you intervene? Could you elaborate what you have in mind

RE: [call to comment] HAProxy's DNS resolution default query type

> I second this opinion. Removing ANY altogether would be the best case. > > In reality, I think it should use the OS's resolver libraries which > in turn will honor whatever the admin has configured for preference > order at the base OS level. > > > As a sysadmin, one should reasonably expect that

RE: SIGUSR1 soft stop does not send "Connection: close"

> From my reading of the code SIGUSR1 does not send a "Connection: close" to the > client or server. This means it is not possible to safely close a keep-alive > session, before terminating HAProxy. > > Would there be interest in a patch to send "Connection: close" on both the > request and the res

RE: [call to comment] HAProxy's DNS resolution default query type

> Jan, a fellow HAProxy user, already reported me that ANY query types > are less and less fashion (for many reasons I'm not going to develop > here). > > Amongs the many way to fix this issue, the one below has my preference: > A new resolvers section directive (flag in that case) which prevent >

RE: [call to comment] HAProxy's DNS resolution default query type

Hi folks, > Hey guys, > > by default, HAProxy tries to resolve server IPs using an ANY query > type, then fails over to resolve-prefer type, then to "remaining" > type. > So ANY -> A -> or ANY -> -> A. We can't really rely on ANY queries, no. Also see [1], [2]. > Today, 0yvind repor

RE: Segfault bug in 1.6.0 release (SNI related maybe)

Hi Øyvind, > Hi, > > When testing the 1.6.0 release we encountered a segfault bug on the > server when trying to run the https://www.ssllabs.com/ssltest/ test on > our two sites running with two different SSL certs. The test runs fine > when its run against one of the sites / certificates, but whe

RE: 1.6 segfaults

> So you may be right on the two certs on the same line bug. Just removed > one of the certs and so far, so good. Can you verify? Are both or one of them (first or second one) wildcard certificates? Thanks, Lukas

RE: req_ssl_ver ACL not working

Hi Julien, > Still, I would like to take a look at the patch and get it fixed properly. Your patch works for me if I only apply the one-line change at "version = (data[9] << 16) + data[10];" Can you confirm that this works for you as well and resubmit it for inclusion? Thanks, Lukas

RE: req_ssl_ver ACL not working

>> jve.linuxwall.info as SNI value? I suggest to remove the >> SNI if statement while testing the TLS ACL. > > Argh... I can't count the number of times forgetting -servername in > openssl s_client got me looking for a bug. This one included. > > "acl tls12 req.payload(9,2) -m bin 0303" works as ex

RE: HA-Proxy IP ranges for acl

> acl allowed_clients hdr_sub(X-Real-IP) 10.10.200.0/24 [...] This is a *string* comparison. You will have to use "req.hdr_ip" [1]: acl allowed_clients req.hdr_ip(X-Real-IP,-1) 10.10.200.0/24 [...] Regards, Lukas [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.6-req.hd

RE: redirect prefix in v1.5.14 and v1.4.22

Hi Diana, > Hello, > > I have two hosts, one has haproxy 1.4.22 installed and the other has > haproxy 1.5.14 installed. > The following rewrite config works as expected in 1.5.14, but not in v1.4.22: You probably want to check whether both 1.4.22 and 1.5.14 executables have been build with

RE: req_ssl_ver ACL not working

> frontend https-in > bind 0.0.0.0:443 > mode tcp > tcp-request inspect-delay 5s > tcp-request content accept if { req_ssl_hello_type 1 } > > acl sni_jve req.ssl_sni -i jve.linuxwall.info > acl tls12 req.payload(9,2) -m bin 0303 > acl sslv3 req_ssl_ver 3.0 > > use_backend jve_https if sni_jve tls12

RE: HA-Proxy IP ranges for acl

> Hi! > > I'd like to report a bug I do experience, > maybe I'm not the first one to report it: > it's about IP network ranges and acl in haproxy (1.5.8). > It's working… sometimes. > I have no issue with ranges like /24 (like 10.10.200.0/24) > But it is not working with a range like /22 ; /28 ; /2

RE: req_ssl_ver ACL not working

> Attached is a patch that should work but doesn't. (bare with me, I'm in > unknown codebase territory here). > > I also tried to match directly using req.payload, and I can't get the > ACL to match: > acl tls12 req.payload(9,2) -m bin 0303 "req.payload(9,2) -m bin 0303" is imho correct, this shou

RE: OPTIM : IPv6 literal address parsing

Hi Mildis, >> And regarding "2001:db8::1234", you can't forbit it simply because you >> don't know if 1234 is a port or not in this context, as you have >> reported. > > Sure. In this very specific case 1234 can’t be a port as 2001:db8:: is > then a subnet. For the record: you can't know that, u

RE: req_ssl_ver ACL not working

Hi Julien, >> Maybe you can also try with "curl --tlsv1.2" which should use a 3.3 >> version. > > That's a very interesting details. Indeed curl sets the HELLO version to > 0x0303 > whereas OpenSSL uses 0x0301. Interestingly, both Firefox and Chrome also > use 0x0301 > in the version of the reco

RE: TCP_NODELAY in tcp mode

>> Ok, you may be hitting a bug. Can you provide haproxy -vv output? >> > > > What do you mean? I get the following warning when trying to use this > option in tcp backend/frontend: Yes I know (I didn't realize you are using tcp mode). I don't mean the warning is the bug, I mean the tcp mode is su

RE: TCP_NODELAY in tcp mode

>> Use "option http-no-delay" [1] to disable Nagle unconditionally. > > > This option requires HTTP mode, but I must use TCP mode because our > protocol is not HTTP (some custom protocol over TCP) Ok, you may be hitting a bug. Can you provide haproxy -vv output? Thanks, Lukas

RE: TCP_NODELAY in tcp mode

> Hello, > > The flag TCP_NODELAY is unconditionally set on each TCP (ipv4/ipv6) > connections between haproxy and the server, and beetwen the client and > haproxy. That may be true, however HAProxy uses MSG_MORE to disable and enable Nagle based on the individual situation. Use "option http-no-d

RE: Reg: Invalid response received on specific page

> ilan@ilan-laptop$echo "show errors" | sudo socat > /run/haproxy/admin.sock stdio > > Total events captured on [19/Aug/2015:15:36:43.378] : 3 > > [19/Aug/2015:15:36:18.452] backend nodes (#4): invalid response > frontend localnodes (#2), server web01 (#1), event #2 > src 127.0.0.1:40332

RE: HTTPS to HTTP reverse proxy

> yes. Sorry about that. I was changing my configuration and forgot to > rollback some of the changes. But even after removing, ssl verify > none, the problem is still there. You will have to look at those specific request that don't work. (like a CSS file), try what happens when you request th

RE: HTTPS to HTTP reverse proxy

Hi Roman, > I am publishing horde webmail application. The horde itself is served > internally via http protocol on apache. I suspect the error is that you are enabling SSL on the backend servers towards port 80? Remove "ssl verify none" from the backend server configurations. Lukas

RE: REg: Connection field in HTTP header is set to close while sending to backend server

> Hi Baptiste, > > Thank you very much for the response.That was quick. > > I tired enabling but got following error,  Looks like you're on haproxy 1.4. In your current configuration you are now using tunnel-mode. If this is a new deployment, I would recommend upgrading to haproxy 1.5. Rega

RE: Multi-part message failure during http mode (haproxy 1.5.12)

> Not to spam again, but a request to anyone who has faced this, and > know how to get around or fix it. I checked the source a bit, there is > a reference to multipart message in the compression code only (do not > compress multi-part). Can you share your release, configuration, traces and logs

RE: Cipher strings when cert has empty CN

Hi, > I spent more time debugging the problem. > Here¹s the source snippet from 1.5.2 version of haproxy > (I believe the latest 1.5.14 has the same issue). This is fixed by commit 8068b03467 ("BUG/MINOR: ssl: correctly initialize ssl ctx for invalid certificates") [1], which is in Haproxy 1.5.7

RE: ocsp

> Hi Lukas, > > I made a mistake in my previous email : it works locally AND remotely ! What fixed the problem? This may be useful for others as well. Lukas

RE: ocsp

Hi Marc, > Hi Lukas, > > great intuition :) > > --- > > CONNECTED(0003) > TLS server extension "server name" (id=0), len=0 > TLS server extension "renegotiation info" (id=65281), len=1 > 0001 - > TLS server extension "EC point formats" (id=11), len=4 > - 03 00 01 02 > TLS server ex

RE: ocsp

> Hi Lukas, > > frontend cluster:443 > bind 1.2.3.4:443 ssl strict-sni crt /home/provisionning/0.pem crt > /home/provisionning/cluster.d > default_backend cluster > capture request header Host len 255 Can you confirm there is no SSL intercepting device in front of the webserver, like hardware fi

RE: ocsp

Hi Marc, > Hi all, > > I have some problem making ocsp stapling working. here is what i did : > > I have 8150.pem with chain, cert and key in it. > > I have 8150.pem.ocsp that seems ok : > > # openssl ocsp -respin 8150.pem.ocsp -text -CAfile alphassl256.chain > OCSP Response Data: > OCSP Respons

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

> Hey guys, > > I haven’t gotten any feedback for this feature. Unless there’s severe > objections, I’ll go ahead and push this to up to master. Emeric responded here: http://marc.info/?l=haproxy&m=143643724320705&w=2 Not sure what you mean by pushing this to master...? Lukas

RE: Test HAProxy configuration file

> Hi Lukas, > > the output of haproxy -c is not helpful. > "Configuration file is valid“  I though thats what you want. > I need a more verbose output with a complete overview of the configuration. > I want to check if options configured in the default or global sections > works for all the

RE: Test HAProxy configuration file

Hi Erik, > Hi, > > is it possible to show and test the configuration of haproxy > like apache2ctl -S? > I want to check with which configuration options haproxy starts. > > Thanks for help.  Yes, see haproxy -h (haproxy -c). Lukas

RE: Segfault when parsing a configuration file

Hi Tomas, > Hello, > > we have a server with some config running an old version (1.4.25-1) of > haproxy under Debian wheezy. The reason we've not updated it is that any > new versions we had access to would crash. > > Today I was able to pinpoint where the problem lies: Thanks for the detailed r

RE: [SPAM] HAProxy soft server turnoff issues

Hi Alexander, > Hello!  >  > My name is Alexander and I am writing on behalf of OWOX company, that  > supports the most visited Ecommerce website in Ukraine  > (rozetka.com.ua).  >  > We are using haproxy as a well-performance server to balance load  > between our database

RE: [PATCH] MINOR: Add sample fetch to detect Supported Elliptic Curves Extension

>  >> The deprecated req_ssl_* keywords were for compatibility with historic > versions >>> and should not be introduced right now, so I'd rather not add it now to >>> remove >>> it in next version. If you're OK with me removing it by hand I can fix it >>> myself, but if you prefer to resubmit th

RE: Issues with force-sslv3

> Thanks Lukas, > > So its either SSLv3 is enable for all, or its disable for all? No, you can disable it per bind line, only that you need to do it the other way around, specifying no-sslv3 on all other bind lines, not the one where you need sslv3 (and not in the defaults). Lukas

RE: [ANNOUNCE] haproxy-1.5.14

> Hi, just to let you know changelog is missing 1.5.14 infos ;) Its there, its probably just cached in your browser (try ctrl+shift+R). Lukas

RE: Issues with force-sslv3

Hi, > Hi there, > > I'm running haproxy 1.5.12 and I have set 'ssl-default-bind-options > no-sslv3 no-tlsv10' (without the quotes of course) under the global > section as I want all my front-ends not to support SSLv3 or TLS1.0. > > However I do have a client that still requires SSLv3 suppor

RE: Now follows SNI rules, except from curl on OSX

> Yep, it's OS X curl.  >  > curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1  > SecureTransport zlib/1.2.5  > Protocols: dict file ftp ftps gopher http https imap imaps ldap  > ldaps pop3 pop3s rtsp smtp smtps telnet tftp  > Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL lib

RE: Now follows SNI rules, except from curl on OSX

That should have read: > The capture shows that there is *no* SNI emitted by the client. I think your > node.js SNI tests was bogus, and that curl doesn't properly support SNI > *if* the crypto library is SecureTransport instead of openssl, gnutls or > cyassl.

RE: Now follows SNI rules, except from curl on OSX

> sudo tcpdump -ps0 -i eth0 -w eth0.64443.cap tcp port 64443 > > And then this on my Yosemite Mac > > curl > --insecure https://baz.example.com:64443 > > And here's the result The capture shows that there is now SNI emitted by the client. I thin

RE: Now follows SNI rules, except from curl on OSX

> But when I use curl bundled with Yosemite (or from Brew) on my macbook, > it's not switching. > > curl --insecure https://bar.example.com:64443 > Default on 1443 > > These are the versions I'm testing with: > > curl --version > curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1 > Sec

RE: very simple SNI rules are only sometimes followed

> oops, I still had the link to the pastebinit, which doesn't work on > binary files. > > https://dropsha.re/files/orange-hound-85/64443-traffic.default.cap > https://dropsha.re/files/angry-dragon-19/64443-traffic.baz.cap Looks alright. Can you configure logging and check the result: globa

RE: very simple SNI rules are only sometimes followed

> To limit verbosity I just captured one full request where it succeeded > and then another when it didn't > > # this is the one that worked as expected > pastebinit dump.1.tls.bin > http://paste.ubuntu.com/11811750/ > > # this is the one that went to default anyway >

RE: very simple SNI rules are only sometimes followed

> sudo haproxy -db -f /etc/haproxy/haproxy.cfg Backend IPs are 0.0.0.0. Thats probably not what you want. Should be 127.0.0.1 if I understand correctly. > I've edited /etc/hosts so that baz.example.com > points to 127.0.0.1 > > I've created a few bogus server

<    4   5   6   7   8   9   10   11   12   13   >