SameSite attribute for persistent session cookie
Hello, With Chrome 80 release in february, HAProxy persistent session cookie will not be working anymore for sites embedded into iframe on multiple domains. See issue https://github.com/haproxy/haproxy/issues/361 Have you planned something to manage that point soon ? Thank you, Mickaël _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Re: [PATCH] MINOR: ssl: accept 'verify' bind option with 'set ssl cert'
On Mon, Jan 20, 2020 at 05:33:53PM +0100, Emmanuel Hocdet wrote: > Hi, > > A last patch for today. > > ++ > Manu Good point, merged. Thanks! -- William Lallemand
[PATCH] MEDIUM: dns: support for Additional section
Hi there, For those using DNS service discovery through SRV record, you might be aware that HAProxy is quite verbose with your DNS server: it does one SRV query + 1 A/ per server found in the SRV response. This patch aims at improving this behavior par using first Additional records if available and relevant. If none found, previous behavior will apply (on a per server basis). This is behavior defined in RFC 2782 for DNS SRV records. Baptiste From a18ab5880ee04b75234eb65ca8a8be4a425d5ba6 Mon Sep 17 00:00:00 2001 From: Baptiste Assmann Date: Fri, 7 Jun 2019 09:40:55 +0200 Subject: [PATCH] MEDIUM: dns: use Additional records from SRV responses Most DNS servers provide A/ records in the Additional section of a response, which correspond to the SRV records from the Answer section: ;; QUESTION SECTION: ;_http._tcp.be1.domain.tld. IN SRV ;; ANSWER SECTION: _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A1.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A8.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A5.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A6.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A4.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A3.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A2.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A7.domain.tld. ;; ADDITIONAL SECTION: A1.domain.tld. 3600IN A 192.168.0.1 A8.domain.tld. 3600IN A 192.168.0.8 A5.domain.tld. 3600IN A 192.168.0.5 A6.domain.tld. 3600IN A 192.168.0.6 A4.domain.tld. 3600IN A 192.168.0.4 A3.domain.tld. 3600IN A 192.168.0.3 A2.domain.tld. 3600IN A 192.168.0.2 A7.domain.tld. 3600IN A 192.168.0.7 SRV record support was introduced in HAProxy 1.8 and the first design did not take into account the records from the Additional section. Instead, a new resolution is associated to each server with its relevant FQDN. This behavior generates a lot of DNS requests (1 SRV + 1 per server associated). This patch aims at fixing this by: - when a DNS response is validated, we associate A/ records to relevant SRV ones - set a flag on associated servers to prevent them from running a DNS resolution for said FADN - update server IP address with information found in the Additional section If no relevant record can be found in the Additional section, then HAProxy will failback to running a dedicated resolution for this server, as it used to do. This behavior is the one described in RFC 2782. --- include/types/dns.h| 4 +- include/types/server.h | 1 + src/dns.c | 216 + src/server.c | 9 ++ 4 files changed, 229 insertions(+), 1 deletion(-) diff --git a/include/types/dns.h b/include/types/dns.h index 8347e93ab..7e592b285 100644 --- a/include/types/dns.h +++ b/include/types/dns.h @@ -151,6 +151,7 @@ struct dns_answer_item { struct sockaddr address; /* IPv4 or IPv6, network format */ chartarget[DNS_MAX_NAME_SIZE+1]; /* Response data: SRV or CNAME type target */ time_t last_seen; /* When was the answer was last seen */ + struct dns_answer_item *ar_item; /* pointer to a RRset from the additionnal section, if exists */ struct list list; }; @@ -158,7 +159,8 @@ struct dns_response_packet { struct dns_header header; struct list query_list; struct list answer_list; - /* authority and additional_information ignored for now */ + struct list ar_list; /* additional records */ + /* authority ignored for now */ }; /* Resolvers section and parameters. It is linked to the name servers diff --git a/include/types/server.h b/include/types/server.h index 842e033ad..598dfe6d8 100644 --- a/include/types/server.h +++ b/include/types/server.h @@ -142,6 +142,7 @@ enum srv_initaddr { #define SRV_F_COOKIESET0x0100/* this server has a cookie configured, so don't generate dynamic cookies */ #define SRV_F_FASTOPEN 0x0200/* Use TCP Fast Open to connect to server */ #define SRV_F_SOCKS4_PROXY 0x0400/* this server uses SOCKS4 proxy */ +#define SRV_F_NO_RESOLUTION 0x0800 /* disable runtime DNS resolution on this server */ /* configured server options for send-proxy (server->pp_opts) */ #define SRV_PP_V1 0x0001 /* proxy protocol version 1 */ diff --git a/src/dns.c b/src/dns.c index 5ecb46905..eefd8d0dc 100644 --- a/src/dns.c +++ b/src/dns.c @@ -516,6 +516,14 @@ static void dns_check_dns_response(struct dns_resolution *res) struct server *srv; struct dns_srvrq *srvrq; + /* clean up obsolete Additional r
Re: [PATCH] BUG/MINOR: ssl: fix 3 memory leaks with set ssl cert
On Mon, Jan 20, 2020 at 05:09:59PM +0100, Emmanuel Hocdet wrote: > > Hi, > > Fix memory leaks with « set ssl cert ». > > ++ > Manu > > Thanks, merged! -- William Lallemand
Re: SameSite attribute for persistent session cookie
Le 21/01/2020 à 09:14, mickael.br...@orange.com a écrit : Hello, With Chrome 80 release in february, HAProxy persistent session cookie will not be working anymore for sites embedded into iframe on multiple domains. See issue https://github.com/haproxy/haproxy/issues/361 Have you planned something to manage that point soon ? Hi, Here is a quick patch that should fix the issue. It is a generic way to add attributes to a cookie. For instance: cookie SRV insert secure attr "SameSite=Strict" Any comments ? -- Christopher Faulet >From 8ccc4396ed93ac91f24595061f5b29e28797116a Mon Sep 17 00:00:00 2001 From: Christopher Faulet Date: Tue, 21 Jan 2020 11:06:48 +0100 Subject: [PATCH] MINOR: proxy/http-ana: Add support of extra attributes for the cookie directive It is now possible to insert any attribute when a cookie is inserted by HAProxy. Any value may be set, no check is performed except the syntax validity (CTRL chars and ';' are forbidden). For instance, it may be used to add the SameSite attribute: cookie SRV insert attr "SameSite=Strict" The attr option may be repeated to add several attributes. This patch should fix the issue #361. --- doc/configuration.txt | 7 ++- include/types/proxy.h | 1 + src/cfgparse-listen.c | 30 +- src/haproxy.c | 1 + src/http_ana.c| 3 +++ 5 files changed, 40 insertions(+), 2 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 93b9c6543..0988b3034 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -3340,7 +3340,7 @@ compression offload cookie [ rewrite | insert | prefix ] [ indirect ] [ nocache ] [ postonly ] [ preserve ] [ httponly ] [ secure ] [ domain ]* [ maxidle ] [ maxlife ] - [ dynamic ] + [ dynamic ] [ attr ] Enable cookie-based persistence in a backend. May be used in sections : defaults | frontend | listen | backend yes |no| yes | yes @@ -3499,6 +3499,11 @@ cookie [ rewrite | insert | prefix ] [ indirect ] [ nocache ] The cookie will be regenerated each time the IP address change, and is only generated for IPv4/IPv6. +attr This option tells haproxy to add an extra attribute when a + cookie is inserted. The attribute value can contain any + characters except control ones or ";". This option may be + repeated. + There can be only one persistence cookie per HTTP backend, and it can be declared in a defaults section. The value of the cookie will be the value indicated after the "cookie" keyword in a "server" statement. If no cookie diff --git a/include/types/proxy.h b/include/types/proxy.h index c018c26f8..c6b56aa5b 100644 --- a/include/types/proxy.h +++ b/include/types/proxy.h @@ -338,6 +338,7 @@ struct proxy { int cookie_len; /* strlen(cookie_name), computed only once */ char *cookie_domain; /* domain used to insert the cookie */ char *cookie_name; /* name of the cookie to look for */ + char *cookie_attrs; /* list of attributes to add to the cookie */ char *dyncookie_key; /* Secret key used to generate dynamic persistent cookies */ unsigned int cookie_maxidle; /* max idle time for this cookie */ unsigned int cookie_maxlife; /* max life time for this cookie */ diff --git a/src/cfgparse-listen.c b/src/cfgparse-listen.c index 86d1f3366..3f16a2517 100644 --- a/src/cfgparse-listen.c +++ b/src/cfgparse-listen.c @@ -326,6 +326,8 @@ int cfg_parse_listen(const char *file, int linenum, char **args, int kwm) curproxy->rdp_cookie_name = strdup(defproxy.rdp_cookie_name); curproxy->rdp_cookie_len = defproxy.rdp_cookie_len; + if (defproxy.cookie_attrs) +curproxy->cookie_attrs = strdup(defproxy.cookie_attrs); if (defproxy.lbprm.arg_str) curproxy->lbprm.arg_str = strdup(defproxy.lbprm.arg_str); @@ -476,6 +478,7 @@ int cfg_parse_listen(const char *file, int linenum, char **args, int kwm) free(defproxy.rdp_cookie_name); free(defproxy.dyncookie_key); free(defproxy.cookie_domain); + free(defproxy.cookie_attrs); free(defproxy.lbprm.arg_str); free(defproxy.capture_name); free(defproxy.monitor_uri); @@ -988,9 +991,34 @@ int cfg_parse_listen(const char *file, int linenum, char **args, int kwm) err_code |= ERR_WARN; curproxy->ck_opts |= PR_CK_DYNAMIC; } + else if (!strcmp(args[cur_arg], "attr")) { +char *val; +if (!*args[cur_arg + 1]) { + ha_alert("parsing [%s:%d]: '%s' expects as argument.\n", + file, linenum, args[cur_arg]); + err_code |= ERR_ALERT | ERR_FATAL; + goto out; +} +val = args[cur_arg + 1]; +while (*val) { + if (iscntrl(*val) || *val == ';') { + ha_alert("parsing [%s:%d]: character '%%x%02X' is not permitted in attribute value.\n", + file, linenum, *val); + err_code |= ERR_ALERT | ERR_FATAL; +
Re: [PATCH] ssl certificates load speedup and dedup (pem/ctx)
Hi,Patches updated, depend on "[PATCH] BUG/MINOR: ssl: ssl_sock_load_pem_into_ckch is not consistent"++ManuLe 10 avr. 2019 à 13:23, Emmanuel Hocdeta écrit :Hi,Updated patch serie:Fix OpenSSL < 1.0.2 compatibilty.More generic key for issuers ebtree.++Manu 0001-MINOR-ssl-add-issuer-path-directive.patch Description: Binary data 0002-MINOR-ssl-cli-set-ssl-issuer-load-an-issuer-certific.patch Description: Binary data
Re: SameSite attribute for persistent session cookie
Christopher, Am 21.01.20 um 11:49 schrieb Christopher Faulet: > Any comments ? > I don't need it myself, but I want to mention that it should be backported, because the current situation can be "considered a bug" (a feature now longer works due to changes in the ecosystem). I guess the patch is fairly low risk, so backport until 1.8 or so? Best regards Tim Düsterhus
Re: SameSite attribute for persistent session cookie
Hello, On Tue, 21 Jan 2020 at 13:09, Tim Düsterhus wrote: > I don't need it myself, but I want to mention that it should be > backported, because the current situation can be "considered a bug" (a > feature now longer works due to changes in the ecosystem). I guess the > patch is fairly low risk, so backport until 1.8 or so? I agree we probably have to backport this (now) necessary *feature*, but I don't believe there is a need to masquerade it as a bug. Lukas
RE: SameSite attribute for persistent session cookie
Hello, I have tested the patch provided by Christopher. It seems to work well. Do you know if it will be available in an official release soon? Agree with the backport on 1.X branch, with the same question for the planning. Thank you, Mickaël -Message d'origine- De : Lukas Tribus [mailto:li...@ltri.eu] Envoyé : mardi 21 janvier 2020 13:53 À : Tim Düsterhus Cc : Christopher Faulet; BRIDE Mickaël SCE/OGSB; haproxy@formilux.org Objet : Re: SameSite attribute for persistent session cookie Hello, On Tue, 21 Jan 2020 at 13:09, Tim Düsterhus wrote: > I don't need it myself, but I want to mention that it should be > backported, because the current situation can be "considered a bug" (a > feature now longer works due to changes in the ecosystem). I guess the > patch is fairly low risk, so backport until 1.8 or so? I agree we probably have to backport this (now) necessary *feature*, but I don't believe there is a need to masquerade it as a bug. Lukas _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Re: [PATCH] introduce ARM64 travis-ci builds
On Sun, Jan 19, 2020 at 12:18:00PM +0500, ??? wrote: > hello, > > sometimes arm64 builds fails, I think it is good chance to introduce > regular builds > and fix them. > > also, few small improvements. Merged, thanks Ilya. Next time, please be stricter and split your additions and your small improvements as it can help track down issues or do partial reverts. Willy
Re: [PATCH] better anti replay check
On Sun, Jan 19, 2020 at 12:22:17PM +0500, ??? wrote: > Hello, > > let us check constants, not openssl versions. Makes sense, thanks. Now merged (and added a commit message). Willy
Re: SameSite attribute for persistent session cookie
Hi guys, On Tue, Jan 21, 2020 at 11:49:43AM +0100, Christopher Faulet wrote: > Le 21/01/2020 à 09:14, mickael.br...@orange.com a écrit : > > Hello, > > > > With Chrome 80 release in february, HAProxy persistent session cookie > > will not be working anymore for sites embedded into iframe on multiple > > domains. > > > > See issue https://github.com/haproxy/haproxy/issues/361 > > > > Have you planned something to manage that point soon ? Well, first, let's cool down a little bit. Browsers normally don't break the web, or when they do so, it takes years or decades. Otherwise their users simply roll back to the previous version or switch to more conservative competitors. If some sites are totally insecure and stop working, it will not be a big loss but these sites will not change any of their components either. Most of the internet's infrastructure cannot afford to perform major upgrades to new compoents just because some browser developers woke up a morning thinking how cool it could be to drop support for something currently working fine. > Here is a quick patch that should fix the issue. It is a generic way to add > attributes to a cookie. For instance: > >cookie SRV insert secure attr "SameSite=Strict" > > Any comments ? I do :-) We should add "*" after the "[ attr ... ]" field in the doc since you allow to repeat the attribute. I did it and merged it. Thanks! Willy
Re: [PATCH] MEDIUM: dns: support for Additional section
Hi Baptiste, On Tue, Jan 21, 2020 at 10:38:37AM +0100, Baptiste wrote: > Hi there, > > For those using DNS service discovery through SRV record, you might be > aware that HAProxy is quite verbose with your DNS server: it does one SRV > query + 1 A/ per server found in the SRV response. > This patch aims at improving this behavior par using first Additional > records if available and relevant. If none found, previous behavior will > apply (on a per server basis). > This is behavior defined in RFC 2782 for DNS SRV records. Interesting, thanks for this. I've merged it, I count on you to recheck the few TODO points that appear in this patch before the final release. Thanks, Willy
Re: [PATCH] improving ssl defines
Hi Ilya, On Sat, Jan 18, 2020 at 06:47:48PM +0500, ??? wrote: > Hello, > > let us switch to constants check, not versions. > > cheers, > Ilya Shipitcin > From a8b68e746bb71c4fee65a05bea8287ad970c979c Mon Sep 17 00:00:00 2001 > From: Ilya Shipitsin > Date: Sat, 18 Jan 2020 18:42:45 +0500 > Subject: [PATCH] BUG/MINOR: ssl: fix build on openssl-1.1.0 > > while working on issue #429, I built various openssl versions, > let us improve ssl defines, switch to features, not versions What is the build issue you've encountered exactly (and/or in what specific environment), and should this build fix be backported, and if so, how far ? Thanks, Willy
Re: [PATCH] improving ssl defines
ср, 22 янв. 2020 г. в 11:24, Willy Tarreau : > Hi Ilya, > > On Sat, Jan 18, 2020 at 06:47:48PM +0500, ??? wrote: > > Hello, > > > > let us switch to constants check, not versions. > > > > cheers, > > Ilya Shipitcin > > > From a8b68e746bb71c4fee65a05bea8287ad970c979c Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Sat, 18 Jan 2020 18:42:45 +0500 > > Subject: [PATCH] BUG/MINOR: ssl: fix build on openssl-1.1.0 > > > > while working on issue #429, I built various openssl versions, > > let us improve ssl defines, switch to features, not versions > > What is the build issue you've encountered exactly (and/or in what > specific environment), and should this build fix be backported, and if > so, how far ? > > I think it should not be backported. I've taken openssl branches (master, openssl_1_1_1 and openssl_1_1_0) and built haproxy against various commits (not tagged as releases). sometimes build fail, I ended with changing "ifdef" from version-dependendent (which is not accurate) to feature dependent. I can find particular commits, but I think it is not important since released versions of openssl build just fine (I'll provide detailed info if build will ever fail on openssl release). > Thanks, > Willy >
Re: [PATCH] CLEANUP: Consistently `unsigned int` for bitfields
On Sat, Jan 18, 2020 at 11:41:58AM +0100, Tim Düsterhus wrote: > Fair enough. In the specific implementation of gcc it might be okay. But > that doesn't say anything about clang (but I guess it's okay as well). Clang tries hard to support whatever gcc does and when I mean gcc I implicitly also mean clang (and very likely icc as well for those who care). > > For this reason I'd like to get the signed-vs-unsigned part merged. > > Feel free to edit around in my patch to remove the bits that change from > something to `int` and leave the adding of the `unsigned` in there. Or > drop my patch, create your own one and add me as Co-authored-by or > Reported-by or whatever. OK so I simply edited your patch. > While doing so please check on the `struct pat_time` I mentioned in my > previous email. Ah yes, good point. I've just checked, I added this in 2007 and never implemented the time range parser. I we managed not to need if for the last 13 years, I think we don't need it and the day we need it we might do it differently, so I'm simply removing that definition. thanks! Willy
Re: [PATCH] MINOR: http_act: enforce capture rule id checking in frontends only
Hi Baptiste, On Thu, Jan 16, 2020 at 02:50:30PM +0100, Baptiste wrote: > From c8192107c7055e36a6b6ab9b262b448a52346776 Mon Sep 17 00:00:00 2001 > From: Baptiste Assmann > Date: Thu, 16 Jan 2020 14:34:22 +0100 > Subject: [PATCH] MINOR: http_act: don't check capture id in backend (...) I retagged it as BUG/MINOR since it's indeed a fix, and marked it for backport to all stable versions. Thanks! Willy
Re: [PATCH] improving ssl defines
On Wed, Jan 22, 2020 at 11:32:43AM +0500, ??? wrote: > I've taken openssl branches (master, openssl_1_1_1 and openssl_1_1_0) and > built haproxy against various commits (not tagged as releases). > sometimes build fail, I ended with changing "ifdef" from > version-dependendent (which is not accurate) to feature dependent. > > I can find particular commits, but I think it is not important since > released versions of openssl build just fine (I'll provide detailed info if > build will ever fail on openssl release). OK thanks, I'll try to summarize that into the commit message. Willy
Re: Enhancement plugin feature for haproxy
On Mon, Jan 20, 2020 at 10:06:20PM +0100, Christopher Faulet wrote: > Nuster evolves in parallel of > HAProxy. It is a fork of it, it is not a patchset on top of it. The nuster > developer never tried to make its project compatible with HAProxy. Or at > least, he never asked anything on the mailing list. So, of course, it is its > own right. There is no problem with that. But it could be a good idea to > have a better view on how the project will evolve to evaluate the pertinence > of a nuster plugin. Honestly, if you ever do the effort to work on it, it > could be better to rewrite all the project as a plugin of HAProxy and not a > fork of it. If so, it is probably a better idea to keep it in a separate > repository though. This will be easier to push new features, without the > burden to submit the patches on the ML. I totally agree with this. If some minor extensions to haproxy would be needed to do his thing better (maybe one hook here and there), we could get them merged to ease his maintenance as long as they have zero impact on the rest. But given that the project has been evolving for a few years now, occasionally rebasing on new version, I guess the developer possibly makes a living from his fork and has no particular interest in seeing his code more easily used without him being kept in the loop. Of couse I could be totally wrong but that's what it makes me think of. I don't think we should bother him. He took care of renaming the project so as to present it as a self-contained cache and not as a load balancer, and as such he doesn't cause any harm to the haproxy project. And he seems to be doing his job right by regularly merging stable branches, so I'm not seeing anything wrong there that we should encourage to change. If all projects forks were done this way, we'd all have less crap installed on our machines. Of course it would be nice if he would participate a bit to the project, but well, how could we expect any contribution back from anyone using haproxy ? He will already have a tough work migrating to HTX :-) Aleks, if you're interested in this project, I think you should contact him. I suspect he will tell you he only covers the caching part and uses haproxy only as the HTTP/TCP engine to run his cache, as is visible in his example config, and that if you want to use a load balancer, he will invite you to use a separate haproxy process. And that's important given that he's doing file system accesses (hence high latencies and limited security)! Regards, Willy