RE: Add secure to all cookies passed to the client

[Ricardo]

Hello Baptiste,

Of course, this is the long explanation:

First of all, this is a scheme of the infraestructure, and the cookies inserted 
in every stage:

Internet --> haproxy:443 https --> haproxy:80 http      --> 
application-backend:80
Internet <--         none               <--   WEBSERVERID   <--      JSESSIONID

The haproxy:443 is used only as a ssl termination, and redirect all the traffic 
to the haproxy:80 whit this (part of) configuration:

frontend proxy-ssl
        bind IP:443 name https ssl crt /etc/haproxy/certs/cert-ca.pem ciphers 
RC4:HIGH:!aNULL:!MD5
        mode http
        option httplog
        option httpclose
        reqadd      X-Proto:\ SSL
...
default_backend back-http

backend back-http
        timeout server          3s
        server bal1 IP:80


The haproxy:80 receive the traffic from the haproxy:443 and from Internet too, 
this is the other part of the configuration:

frontend proxy-http
        bind IP:80
        mode http
        option httplog
        option httpclose
        option forwardfor
...
default_backend backend-http

backend backend-http
        timeout server          3s
        option httpchk GET /testing
        http-check expect string RUN
        cookie WEBSERVERID insert maxidle 60m maxlife 180m indirect
        server web1 IP:80 cookie A check inter 5s fastinter 1s downinter 1s 
rise 2 fall 2
        server web2 IP:80 cookie B check inter 5s fastinter 1s downinter 1s 
rise 2 fall 2
        server web3 IP:80 cookie C check inter 5s fastinter 1s downinter 1s 
rise 2 fall 2
        server web4 IP:80 cookie D check inter 5s fastinter 1s downinter 1s 
rise 2 fall 2
        server web5 IP:80 cookie E check inter 5s fastinter 1s downinter 1s 
rise 2 fall 2


Whit this conf, the result of the cookies passed to the client is this:

Set-Cookie: JSESSIONID=1EAA38A1BD418EB1A79DD64E1AE9A407; Path=/; HttpOnly
Set-Cookie: WEBSERVERID=B|Us5p2|Us5p2; path=/

But I'm looking for secure this cookies in the haproxy:443. If I modify the 
conf in the backend of this balancer with "cookie WEBSERVERID rewrite secure", 
the result is the same.

If I modify to "cookie WEBSERVERID insert secure", the result is this:

Set-Cookie: JSESSIONID=1EAA38A1BD418EB1A79DD64E1AE9A407; Path=/; HttpOnly
Set-Cookie: WEBSERVERID=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; Secure

But I'm looking for a complete rewrite of all cookies without loosing 
information and with the secure option. Is it possible?


Thanks,




> Date: Wed, 8 Jan 2014 17:14:02 +0100
> Subject: Re: Add secure to all cookies passed to the client
> From: bed...@gmail.com
> To: ri...@hotmail.com
> CC: haproxy@formilux.org
>
> Hi Ricardo,
>
> Could you please send us an example of before/after modification?
> Cause I can't see what you want to modify.
>
> Baptiste
>
>
> On Wed, Jan 8, 2014 at 5:09 PM, Ricardo  wrote:
>> Hello,
>>
>>
>> I am using HA-Proxy version 1.5-dev19 2013/06/17 for ssl termination, behind 
>> that, there are other haproxy balancing over 5 servers in http.
>>
>> This bottom http haproxy insert the usually cookie "WEBSERVER" for stick the 
>> connections to the proper backend. Like this:
>>
>> Set-Cookie: WEBSERVERID=V|Us1vO|Us1vO; path=/
>>
>> But, in the top https haproxy, I want to add the "secure" attribute to the 
>> cookie provided by the bottom http haproxy and others provided by the 
>> application, like JSESSIONID.
>>
>> How can I add "secure" to all cookies passed to the client?
>>
>>
>> Thanks,
>>
>> Ricardo F.
> 

RE: Thousands of FIN_WAIT_2 CLOSED ESTABLISHED in haproxy1.5-dev21-6b07bf7

[Lukas Tribus]

Hi,

> Thanks very much for your answer !
> Actually, we just used FreeBSD9.2 with the same configuration before,
> but the situation almost the same :(

Ok, at least its not likely to be a OS bug then.



> And is there any other possible reason there ? Or is there any
> possible tools for track the problem ?

Like I said, you will need to reproduce the problem on a box with
no traffic at all - so the impact of a single connection can be analyzed
(sockets status on the frontend/backend, for example).

Its nearly impossible to this on a busy box with a lot of production traffic.

Also, the configuration needs to be trimmed down to a single, specific use
case (you already said you suspect a specific backend).



Regards,

Lukas 

Unix socket question

[Craig Smith]

Hello.

I'm attempting to use HA Proxy with some custom scripts with auto scaling
groups on EC2. If I run the 'disable server' command from a Unix socket
what will happen to that active connections to that server? Will HAP wait
until those connections are closed to mark the server down?

Thanks.

Craig

HAProxy 1.5

[Kobus Bensch]

Hi

Have you got a date for the final release of 1.5? There are a few 
features in 1.5 we badly need.


Thanks

Kobus

--


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 1.5

[PiBa-NL]

Hi

If you need it badly then start using it. (after validating&testing with 
your configuration which you should do anyway.)


The name 'release' wont say there wont be any bugs left. As for the 
current 1.5devX releases lots of people use them in production 
environments and they are in general very stable.


As for testing with your current configuration you should actually start 
doing that a.s.a.p. so if you do find there are problems they can still 
be fixed before the release is called 'final'.


And for a date that would be "1.5 (ETA 2013/12/31)" (see roadmap in 
git.), besides that one and maybe some other estimations you probably 
wont get the actual date it until its really ready.. And it will be 
ready when its ready. As you might have read the 'release' is coming 
closer every day, as most major features are now implemented, and only a 
few development builds will probably be made for some final bug fix 
checks...


Greets PiBa-NL
Find below part of the 1.5dev20 release mail from Willy as the 
mailinglist archives are not containing this.. (followed a day later by 
dev21 to fix a small but annoying issue):

"""

I expect to release 1.5-final around January and mostly focus on chasing
bugs till there. So I'd like to set a feature freeze. I know it doesn't
mean much considering that we won't stop contribs. But I don't want to
merge another large patch set before the release. Ideally there will not
be any dev21 version. Reality probably is that we'll have to issue one
because people will inevitably report annoying bugs that were not reported
in snapshots.

"""

Kobus Bensch schreef op 9-1-2014 17:58:

Hi

Have you got a date for the final release of 1.5? There are a few 
features in 1.5 we badly need.


Thanks

Kobus

how to use ASPSESSIONID with stick-table?

[PiBa-NL]

Hi,

While reading about stickyness its seems like there are quite a few options.
*TCP*
1- balance source
2- stick on src
*SSL*
3- stick on payload_lv(43,1) if clienthello
*HTTP/SSLoffloading*
4- cookie 
5- stick on req.cook()
6- appsession 

But while the last 3 options can all use a 'normal' cookie. It seems 
only the appsession can process a "ASPSESSIONID=".


While the stick-table can be synchronized between multiple haproxy 
instances and also has the ability to 'survive' a reload of the 
configuration and a inserted cookie doesn't need any in memory table to 
be matched to the correct backend. Only the 'appsession' will loose all 
needed information to succesfully persist a client to a single backend 
and isn't able to sync.


Ive read that appsession will be deprecated [1], will this happen 
anytime 'soon'? And if so what can be configured to match the way it 
finds and handles cookies.?


As far as i could see "req.cook()" cannot match on the prefix of 
a cookie-name like appsession and "capture cookie" are able to do.? Or 
is there a other more generic option i overlooked.? I did see cook_beg 
but that only checks the prefix of the value not the name.


The question is because i want to change configuration-webgui in a 
pfSense haproxy-devel package and want to include some "easy to 
configure" persistence options.. but want to know if there is a 
alternative to appsessions so everything can be done with either cookies 
and sticktables.


[1] 
http://serverfault.com/questions/550910/haproxy-appsession-vs-cookie-precedence

Hardware recommendations for HAProxy on large-scale site

[Daniel Wilson]

What resources should we look to maximize when building a server to get the
most out of HAProxy?  I read in some forums that more than a 2-core
processor would be wasted on HAProxy.  Is that true? Should we get the most
RAM we can (e.g. 100+ GB)?  Or would some other resource saturate much
faster?  Perhaps the NICs? Speaking of NICs, what do you recommend?  I'm
looking at 10 Gbps NIC's, but should I look at 2?  Or more?  Any particular
brand well-proven?  Or any to avoid?

 

Thanks for the help!

 

Daniel Wilson

Lead Software Developer

The eWhiteboard Company  

 

Loading configuration from multiple files

[Dmitry Borodaenko]

Greetings,

Can the question of loading HAProxy configuration from multiple files
be revisited once again?

The most useful implementation I've found so far is this:
http://marc.info/?l=haproxy&m=129235503410444

Even though it's been a few years, that patch still cleanly applies to
the latest HAProxy 1.4 and 1.5. At the time, it was rejected, and
since then nobody has stepped up to address the concerns that were
raised against it.

As far as I understand, primary reasons this has not yet been merged
or otherwise implemented were:

1) There's already a way to load configuration from multiple files by
specifying multiple "-f" parameters on haproxy command line.

My biggest concern with that approach is that you need an init script
that is tailored to a specific layout of configuration fragment files,
and may break or misbehave if its assumptions about the layout are not
met. Multiply the number of possible layouts by the number of init
systems (SysV init, upstart, systemd, OpenRC etc.) and making this
reasonably generic becomes cumbersome, even before you consider
supporting different Linux distributions.

2) HAProxy configuration is sensitive to the order of sections, and a
fragment of a section placed at the wrong place can break all sorts of
things.

I think the best way to address this is to enforce additional
validation on file fragments, e.g. require that any included file
excplicitly associates each setting line with a section. In other
words, it shouldn't have hanging setting lines that can end up being
associated with a section from another file depending on the file sort
order. Also, AFAIU specifying multiple configuration files on the
command line exposes the same problem, so even merging this patch as
is would at least not make things worse.

3) Unrestricted include directive allows to create an include loop.

I believe that concern is already addressed by the patch linked above
by setting a limit on the nesting level in the
INCLUDE_RECURSION_LEVEL_MAX macro.

Is there any other major problem I've missed?

Thanks,

-- 
Dmitry Borodaenko

Re: http-keep-alive broken?

[Sander Klein]

Hi,

I'm sorry you haven't heard from me yet. But I didn't have time to look 
into this issue. Hope to do it this weekend.


Greets,

Sander