Re: Deny with 413 request too large

[Bryan Talbot]

>>> 
>>>  errorfile 413 /usr/local/etc/haproxy/errors/413.http
>>>  http-request deny deny_status 413 if { req.body_size gt 10485760 }
>>> 
>>> ... HAProxy complains with:
>>> 
>>>  [WARNING] 135/001448 (27) : parsing [/etc/haproxy/haproxy.cfg:15] : status 
>>> code 413 not handled by 'errorfile', error customization will be ignored.
>>>  [WARNING] 135/001448 (27) : parsing [/etc/haproxy/haproxy.cfg:89] : status 
>>> code 413 not handled, using default code 403.
>>> 
>>> How should I configure HAProxy in order to deny with 413?
>> 
> 
> In my understanding I should only use a 400badreq.http like message on an 
> errorfile 400 config line, otherwise if HAProxy need to issue a 400 status 
> code, my 413 status code would be issued instead.
> 
> Is this a valid feature request or there are technical reasons why this has 
> been done that way?
> 
> Hints are welcome.


I think the way to do it is to create a backend to handle deny with the special 
message and then use the backend to reject the request. You can have different 
backends to handle any special case and not pollute the normal error responses.

frontend http
… normal stuff here
  use_backend req_too_big if { req.body_size gt 10485760 }


backend req_too_big
  errorfile 400 /path/to/my/error400_req_too_big.http
  http-request deny 400



-Bryan

Re: Deny with 413 request too large

[Joao Morais]

> Em 17 de mai de 2017, à(s) 19:34, Bryan Talbot  
> escreveu:
> 
> 
>> On May 15, 2017, at May 15, 6:35 PM, Joao Morais  
>> wrote:
>> 
>>   errorfile 413 /usr/local/etc/haproxy/errors/413.http
>>   http-request deny deny_status 413 if { req.body_size gt 10485760 }
>> 
>> ... HAProxy complains with:
>> 
>>   [WARNING] 135/001448 (27) : parsing [/etc/haproxy/haproxy.cfg:15] : status 
>> code 413 not handled by 'errorfile', error customization will be ignored.
>>   [WARNING] 135/001448 (27) : parsing [/etc/haproxy/haproxy.cfg:89] : status 
>> code 413 not handled, using default code 403.
>> 
>> How should I configure HAProxy in order to deny with 413?
> 
> 
> You’ve already found it. AFAIK, that’s the only way.


=(

In my understanding I should only use a 400badreq.http like message on an 
errorfile 400 config line, otherwise if HAProxy need to issue a 400 status 
code, my 413 status code would be issued instead.

Is this a valid feature request or there are technical reasons why this has 
been done that way?

Hints are welcome.

~jm

Re: Graceful shutdown of haproxy

[Gold Star]

Thanks for pointing out the obvious flaw Maciej.

Is it possible to modify option #2 (Lua-script powered endpoint) to define
a read-write endpoint where read endpoint (HTTP GET) returns the health
status while the write endpoint (HTTP POST on the same port) will update an
in-memory variable that represents the health status?  We will ensure that
the source IP and port of the caller are valid for security purpose.
Subsequent read responses will change based on the updated value of this
in-memory variable.

Any idea option #2 or option #3 is better or if there are better options
out there?

Thanks!

On Mon, May 22, 2017 at 10:21 AM, Maciej Katafiasz <
mkatafi...@purestorage.com> wrote:

> On 22 May 2017 at 00:23, Gold Star  wrote:
> > We can assume that the decider process sets an environment variable, say
> > HEALTHY, to true or false at any time it wants. We would like an haproxy
> > instance to return a healthy signal iff it is genuinely healthy and the
> > HEALTHY environment variable is set to true.
>
> This can't possibly work, because the POSIX environment is only
> inherited by the process on start, and static afterwards. There's no
> way to update another process's environment.
>
> Cheers,
> Maciej
>

Re: Graceful shutdown of haproxy

[Maciej Katafiasz]

On 22 May 2017 at 00:23, Gold Star  wrote:
> We can assume that the decider process sets an environment variable, say
> HEALTHY, to true or false at any time it wants. We would like an haproxy
> instance to return a healthy signal iff it is genuinely healthy and the
> HEALTHY environment variable is set to true.

This can't possibly work, because the POSIX environment is only
inherited by the process on start, and static afterwards. There's no
way to update another process's environment.

Cheers,
Maciej

Re: OpenSSL engine and async support

[Emeric Brun]

Hi Willy,

On 05/17/2017 10:10 PM, Willy Tarreau wrote:
> Hi Emeric,
> 
> On Wed, May 17, 2017 at 09:49:32PM +0200, Emeric Brun wrote:
>> More fixes, it appears stable now, even if session are closed during 
>> handshake.
>>
>> I also added the support of multiple async engines (latest patch: it is 
>> limited to 32 engines)
>>
>> I did some tests using my home-made engine (algo EC,DH) + QuickAssist (algo
>> RSA) and I checked it handles 2 async fds on the same session.
>>
>> Thanks for your job!
>>
>> Willy: could you merge them?
> 
> Good job! I'll integrate this ASAP (once I lift my nose out of the H2 spec).
> Just one thing, I'm seeing that your bug fixes are against Grant's initial
> patch so I'll merge them together trying to keep most of your comment, in
> order to avoid purposely integrating known bugs ; this would needlessly
> confuse any future backport and bisects.
> 
> Thanks!
> Willy
> 

Sure!

R,
Emeric

Re: [PATCH] MINOR: boringssl: basic support for OCSP Stapling

[Emmanuel Hocdet]

Hi Emeric,

> Le 22 mai 2017 à 14:21, Emeric Brun  a écrit :
> On 03/29/2017 04:46 PM, Emmanuel Hocdet wrote:
>> 
>> Use boringssl SSL_CTX_set_ocsp_response to set OCSP response from file with
>> '.ocsp' extension. CLI update is not supported.
>> 
> 
> Could you add this detail in the doc?
> 

yep:



0001-MINOR-boringssl-basic-support-for-OCSP-Stapling.patch
Description: Binary data


Manu

[PATCH] BUILD: ssl: fix SSL_OP_NO_SSLv3 with LibreSSL >= 2.3.0

[Emmanuel Hocdet]

Hi Cyril,This patch should fix the build issue

0001-BUILD-ssl-fix-SSL_OP_NO_SSLv3-with-LibreSSL-2.3.0.patch
Description: Binary data
Can you check it’s your case?ManuLe 22 mai 2017 à 12:08, Emmanuel Hocdet  a écrit :Hi Cyril,Le 18 mai 2017 à 23:02, Cyril Bonté  a écrit :Hi all,Le 12/05/2017 à 15:13, Willy Tarreau a écrit :Hi guys,On Tue, May 09, 2017 at 11:21:36AM +0200, Emeric Brun wrote:It seems to do what we want, so we can merge it.So the good news is that this patch set now got merged :-)Commit 5db33cbdc4 [1] seems to have broken the compilation when OPENSSL_NO_SSL3 is defined : SSLv3_server_method() and SSLv3_client_method() won't exist in this case.Previously there was a condition to verify this, which has disappeared with this patch set.There is something wrong with that. What is going on if haproxy is build with OPENSSL_NO_SSL3 and library support SSLv3?If library does not support SSLv3, haproxy should compile and disable SSLv3 natively, without this compilation flag.I look at the current LibreSSL include and SSL_OP_NO_SSLv3 is correctly set to 0 => haproxy will build natively without SSLv3.What is the value of SSL_OP_NO_SSLv3 in our ssl library?Perhaps it could be fix in openssl-compat.h.#if LIBRESSL_VERSION_NUMBER >= X#undef SSL_OP_NO_SSLv3#define SSL_OP_NO_SSLv3 0#endifThanks for your time and efforts back-and-forth on this one!Willy[1] http://www.haproxy.org/git?p=haproxy.git;a=commit;h=5db33cbdc4f2952cbd3c140edce0eda84e1447b4-- Cyril Bonté

Re: [PATCH] MINOR: boringssl: basic support for OCSP Stapling

[Emeric Brun]

Hi Manu,

On 03/29/2017 04:46 PM, Emmanuel Hocdet wrote:
> 
> Use boringssl SSL_CTX_set_ocsp_response to set OCSP response from file with
> '.ocsp' extension. CLI update is not supported.
> 

Could you add this detail in the doc?

R,
Emeric

Re: [Patches] TLS methods configuration reworked

[Emmanuel Hocdet]

Hi Cyril,

> Le 18 mai 2017 à 23:02, Cyril Bonté  a écrit :
> 
> Hi all,
> 
> Le 12/05/2017 à 15:13, Willy Tarreau a écrit :
>> Hi guys,
>> 
>> On Tue, May 09, 2017 at 11:21:36AM +0200, Emeric Brun wrote:
>>> It seems to do what we want, so we can merge it.
>> 
>> So the good news is that this patch set now got merged :-)
> 
> Commit 5db33cbdc4 [1] seems to have broken the compilation when 
> OPENSSL_NO_SSL3 is defined : SSLv3_server_method() and SSLv3_client_method() 
> won't exist in this case.
> Previously there was a condition to verify this, which has disappeared with 
> this patch set.
> 

There is something wrong with that. What is going on if haproxy is build with 
OPENSSL_NO_SSL3 and library support SSLv3?
If library does not support SSLv3, haproxy should compile and disable SSLv3 
natively, without this compilation flag.

I look at the current LibreSSL include and SSL_OP_NO_SSLv3 is correctly set to 
0 => haproxy will build natively without SSLv3.
What is the value of SSL_OP_NO_SSLv3 in our ssl library?

Perhaps it could be fix in openssl-compat.h.
#if LIBRESSL_VERSION_NUMBER >= X
#undef SSL_OP_NO_SSLv3
#define SSL_OP_NO_SSLv3 0
#endif

> 
>> Thanks for your time and efforts back-and-forth on this one!
>> Willy
>> 
> 
> [1] 
> http://www.haproxy.org/git?p=haproxy.git;a=commit;h=5db33cbdc4f2952cbd3c140edce0eda84e1447b4
> 
> -- 
> Cyril Bonté

Is it possible to disable SSL if not certificates are found?

[Simos Xenitellis]

Hi All,

I am trying to automate some tasks with adding multiple https
(LetsEncrypt) websites,
and using HAProxy as a TLS Termination Proxy.

The problem is that when you start off with an empty server, there are
no certificates yet,
and it is not possible to have "bind *:443 ssl crt
/etc/haproxy/certs/..." in haproxy.cfg.

LetsEncrypt can work with http, so it could easily use the "bind *:80"
front-end in the beginning.

Is there a way to express "If no certificates are found in
/etc/haproxy/certs/, then do not bind *:443"?

Simos

Graceful shutdown of haproxy

[Gold Star]

Hi,

I am looking for a way to (1) report health from a haproxy instance, such
that (2) the health response is set by another "decider" process on the
same host. What is the best way to go about it? I am using version 1.7.1
but can upgrade if need be.

We can assume that the decider process sets an environment variable, say
HEALTHY, to true or false at any time it wants. We would like an haproxy
instance to return a healthy signal iff it is genuinely healthy and the
HEALTHY environment variable is set to true.

I thought of the following options:

1) Use monitor-uri with 'monitor fail if' clause that uses 'env' fetch
method (https://cbonte.github.io/haproxy-dconv/1.7/
configuration.html#7.3.2-env): This doesn't work since 'env' reads the env
variable only on haproxy start.

2) Expose a different port and URI than monitor-uri for health check (e.g.
/health-uri at port 12345) that is answered by a Lua script. The Lua script
uses os.getenv() to read the HEALTHY env variable as well as ping
monitor-uri and returns a successful result only if both steps are
successful.
The haproxy docs (http://www.arpalert.org/haproxy-lua.html#h204) says that
many Lua functions, especially file access ones, are prohibited as they
block. Is os.getenv() also not allowed?

3) Have a separate inetd-based script running at, say, port 12345 that does
both the steps that the above Lua script does. This solution is hinted at
by the docs (https://cbonte.github.io/haproxy-dconv/1.7/
configuration.html#port).

Is option #2 feasible (os.getenv())? Are there other workable options?
Which of the feasible options is better?

Readers may ask "what are you trying to achieve?", so I will list my use
case as well.

USE CASE: We use haproxy in docker container in our production
environments. Every container in our datacenter is restarted every 2 weeks.
We don't want traffic processing to be disrupted during such planned
restarts. So, we plan to achieve a graceful restart in the following way:

1) Intercept container kill signal issued by Apache Aurora
2) The interception is done by the 'decider' process which then sets
HEALTHY=false
3) This should cause haproxy to fail health signal to upstream systems
(e.g. AWS route 53)
4) This should cause upstream systems to NOT send new requests to haproxy
while at the same time allow it time to finish processing in-flight requests
5) Once in-flight requests are processed completely (as reflected in
connection count or a fixed timeout), the decider process lets the
container shutdown to proceed

Thanks!