Re: [PATCH] BUG/MEDIUM: http: Properly reject non-HTTP/1.x protocols
Hi Tim, On Tue, Mar 10, 2020 at 12:55:40AM +0100, Tim Duesterhus wrote: > This patch hardens the verification of the HTTP/1.x version line > (i.e. the first line within an HTTP/1.x request) to verify that > the protocol name within the version actually reads "HTTP". > > Previously protocols that superficially resembled the wire-format > of HTTP/1.x and having a 4-letter acronym as the protocol name, such > as RTSP would pass this check. It was on purpose that RTSP passes this check, since commit 63d692c, as the message framing and the headers are exactly the same as HTTP. There were a few users. This makes me realize that with HTX it's probably dead anyway since we'll emit HTTP/1.1 and not RTSP/2.0. > This patch fixes GitHub issue #540, it must be backported to all > supported versions. Hmmm no, let's not backport this as we'll break working setups. However since we've broken RTSP in 2.1 we should decide whether we want to continue to support it or definitely drop it. I don't know who uses it :-/ I'll have a look at the issue above (not seen yet). Thanks, Willy
Re: [PATCH] DOC: ssl: clarify security implications of TLS tickets
On Tue, Mar 10, 2020 at 12:56:09AM +0100, Lukas Tribus wrote:
> Clarifies security implications of TLS ticket usage when not
> rotating TLS ticket keys, after commit 7b5e136458 ("DOC:
> improve description of no-tls-tickets").
I indeed prefer this wording which is more accurate and lets the user
decide.
Thanks,
Willy
Re: TLS tickets prone to MITM attacks (was: [PR] Docs tls tickets)
Hello, On Mon, 9 Mar 2020 at 20:39, Илья Шипицин wrote: >> I would disable session tickets by default in haproxy. Given that most >> clients support TLS 1.3 already this change would not even slow down many >> clients. > > > TLS tickets really require more love :) > > actually, there are two bad choices here > > 1) to specify TLS ticket key > 2) not to specify > > if you specify, your security team will tell you that "it is not secure". > if you do not specify, keys are generated on startup and it lead to huge CPU > spike on app reload (if you apply new config, app is reloaded and keys are > generated from scratch) You rotate ticket keys with "tls-ticket-keys" and reload or you can even add new ticket keys online via the "set ssl tls-key" unix socket command. But you have to take care of it if you want ticket key rotation. A performant, scalable and fully secure TLS setup is a non-trivial configuration to make. Probably not possible without compromises in a production environment with real world clients, but that is just how it is. Regarding security aspects the actual attack surface has to be considered. This attack requires the intruder to read the TLS ticket key from memory, this kills the concept of Forward Secrecy, but it does not kill anything else (that would not already be compromised anyway when an attacker can read from memory). Lukas
Re: [PATCH] BUG/MEDIUM: http: Properly reject non-HTTP/1.x protocols
Willy, Thierry, Am 10.03.20 um 00:55 schrieb Tim Duesterhus: > This patch hardens the verification of the HTTP/1.x version line > (i.e. the first line within an HTTP/1.x request) to verify that > the protocol name within the version actually reads "HTTP". > > Previously protocols that superficially resembled the wire-format > of HTTP/1.x and having a 4-letter acronym as the protocol name, such > as RTSP would pass this check. > > This patch fixes GitHub issue #540, it must be backported to all > supported versions. The legacy, non-HTX parser is affected as well, > a fix must be created for it as well. Digging deeper I find commit 63d692c03721d21b6469a97ce7c2e91714fb9408 "MEDIUM: http: allows 'R' and 'S' in the protocol alphabet" from Thierry, introduced in 1.6-dev2 which specifically added support for RTSP (completely undocumented, though). - If RTSP support is desired then it should clearly be documented. - If not then my patch should be updated to remove the "version token" flag from 'R' and 'S' in addition to verifying that the 4 characters are 'HTTP' and not '' or whatever. The commit message must also be updated, because does not pass in any case. Best regards Tim Düsterhus
[PATCH] DOC: ssl: clarify security implications of TLS tickets
Clarifies security implications of TLS ticket usage when not
rotating TLS ticket keys, after commit 7b5e136458 ("DOC:
improve description of no-tls-tickets").
---
doc/configuration.txt | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 0083549..33425a6 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -11677,10 +11677,9 @@ no-tls-tickets
extension) and force to use stateful session resumption. Stateless
session resumption is more expensive in CPU usage. This option is also
available on global statement "ssl-default-bind-options".
- The TLS ticket mechanism is only used up to TLS 1.2 and it is prone to
- man-in-the-middle attacks. You should consider to disable them for
- security reasons. TLS 1.3 implements more secure methods for session
- resumption.
+ The TLS ticket mechanism is only used up to TLS 1.2.
+ Forward Secrecy is compromised with TLS tickets, unless ticket keys
+ are periodically rotated (via reload or by using "tls-ticket-keys").
no-tlsv10
This setting is only available when support for OpenSSL was built in. It
@@ -12380,10 +12379,9 @@ no-tls-tickets
extension) and force to use stateful session resumption. Stateless
session resumption is more expensive in CPU usage for servers. This option
is also available on global statement "ssl-default-server-options".
- The TLS ticket mechanism is only used up to TLS 1.2 and it is prone to
- man-in-the-middle attacks. You should consider to disable them for
- security reasons. TLS 1.3 implements more secure methods for session
- resumption.
+ The TLS ticket mechanism is only used up to TLS 1.2.
+ Forward Secrecy is compromised with TLS tickets, unless ticket keys
+ are periodically rotated (via reload or by using "tls-ticket-keys").
See also "tls-tickets".
no-tlsv10
@@ -12813,6 +12811,9 @@ tls-tickets
This option may be used as "server" setting to reset any "no-tls-tickets"
setting which would have been inherited from "default-server" directive as
default value.
+ The TLS ticket mechanism is only used up to TLS 1.2.
+ Forward Secrecy is compromised with TLS tickets, unless ticket keys
+ are periodically rotated (via reload or by using "tls-ticket-keys").
It may also be used as "default-server" setting to reset any previous
"default-server" "no-tls-tickets" setting.
--
2.7.4
[PATCH] BUG/MEDIUM: http: Properly reject non-HTTP/1.x protocols
This patch hardens the verification of the HTTP/1.x version line
(i.e. the first line within an HTTP/1.x request) to verify that
the protocol name within the version actually reads "HTTP".
Previously protocols that superficially resembled the wire-format
of HTTP/1.x and having a 4-letter acronym as the protocol name, such
as RTSP would pass this check.
This patch fixes GitHub issue #540, it must be backported to all
supported versions. The legacy, non-HTX parser is affected as well,
a fix must be created for it as well.
---
src/h1_htx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/h1_htx.c b/src/h1_htx.c
index af18a98b3..0432c9c43 100644
--- a/src/h1_htx.c
+++ b/src/h1_htx.c
@@ -66,7 +66,7 @@ static int h1_process_req_vsn(struct h1m *h1m, union h1_sl
*sl)
if (sl->rq.v.len != 8)
return 0;
- if (*(sl->rq.v.ptr + 4) != '/' ||
+ if (!istnmatch(sl->rq.v, ist("HTTP/"), 5) ||
!isdigit((unsigned char)*(sl->rq.v.ptr + 5)) ||
*(sl->rq.v.ptr + 6) != '.' ||
!isdigit((unsigned char)*(sl->rq.v.ptr + 7)))
--
2.25.1
Re: SUBVERS broken in 2.1 snapshot
On Mon, Mar 09, 2020 at 08:42:04PM +0100, Tim Düsterhus wrote: > Willy, > > I noticed that within the 2.1 snapshot the SUBVERS file has incorrect > contents: (...) > > 2.1 > > -$Format:%h$ Thanks, an info/attributes file was missing in this repo, there as only ./attributes. Now fixed, next snapshot will be OK. I'm marking the snapshot for automatic regeneration. Willy
SUBVERS broken in 2.1 snapshot
Willy, I noticed that within the 2.1 snapshot the SUBVERS file has incorrect contents: > [timwolla@/tmp [2]]for haproxy_version in 1.8 1.9 2.0 2.1 2.2 >echo $haproxy_version >curl -fsSL > http://www.haproxy.org/download/$haproxy_version/src/snapshot/haproxy-ss-LATEST.tar.gz > |tar xz --strip-components=1 --wildcards --to-stdout '*/SUBVERS' >end > 1.8 > -beacaef > > 1.9 > -bea2911 > > 2.0 > -4ab0efb > > 2.1 > -$Format:%h$ > > 2.2 > -ee3bcdd > Best regards Tim Düsterhus
Re: TLS tickets prone to MITM attacks (was: [PR] Docs tls tickets)
пн, 9 мар. 2020 г. в 23:21, Björn Jacke : > On 2020-03-09 at 17:44 +0100 Lukas Tribus sent off: > > Perhaps we can relax the wording a bit here and describe the actual > > technical issue along with some recommendations. Apache for example > > documents [1]: > > I think the wording from the patch is still quite relaxed :). One of the > best > summaries describing the session ticket flaws, which I recommend is this: > https://blog.filippo.io/we-need-to-talk-about-session-tickets/ > > I would disable session tickets by default in haproxy. Given that most > clients support TLS 1.3 already this change would not even slow down many > clients. > TLS tickets really require more love :) actually, there are two bad choices here 1) to specify TLS ticket key 2) not to specify if you specify, your security team will tell you that "it is not secure". if you do not specify, keys are generated on startup and it lead to huge CPU spike on app reload (if you apply new config, app is reloaded and keys are generated from scratch) > > Björn > >
Re: TLS tickets prone to MITM attacks (was: [PR] Docs tls tickets)
On Mon, 9 Mar 2020 at 19:18, Björn Jacke wrote: > > On 2020-03-09 at 17:44 +0100 Lukas Tribus sent off: > > Perhaps we can relax the wording a bit here and describe the actual > > technical issue along with some recommendations. Apache for example > > documents [1]: > > I think the wording from the patch is still quite relaxed :). One of the best > summaries describing the session ticket flaws, which I recommend is this: > https://blog.filippo.io/we-need-to-talk-about-session-tickets/ Nothing about this is a MITM attack. The point in the article is that when the ticket-key is compromised, captured traffic can be passively decrypted (which is what broken PFS means, as explained by the Apache docs). I agree we should explain the operational issues, just as Apache does, but your patch does not do that. I will send a patch. > I would disable session tickets by default in haproxy. > Given that most clients support TLS 1.3 already this change > would not even slow down many clients. I disagree, the clients are not our only concern. Servers are. And most deployments on the server side are far away from TLS 1.3 support. Lukas
Re: TLS tickets prone to MITM attacks (was: [PR] Docs tls tickets)
пн, 9 мар. 2020 г. в 23:59, Willy Tarreau : > On Mon, Mar 09, 2020 at 07:18:23PM +0100, Björn Jacke wrote: > > On 2020-03-09 at 17:44 +0100 Lukas Tribus sent off: > > > Perhaps we can relax the wording a bit here and describe the actual > > > technical issue along with some recommendations. Apache for example > > > documents [1]: > > > > I think the wording from the patch is still quite relaxed :). One of the > best > > summaries describing the session ticket flaws, which I recommend is this: > > https://blog.filippo.io/we-need-to-talk-about-session-tickets/ > > So as explained in the article above, all of this is only a problem if keys > are *never* rotated. New keys are used every time the process is reloaded, > and those using distributed deployments update them via the "set ssl > tls-key" > command on the CLI which purposely supports old and new key in order to > maintain a distributed state synchronized yet up to date. > maybe it worth separate discussion... there was some discussion on nginx mailing list regarding BoringSSL and TLS tickets (sorry for link to discussion in russian) https://forum.nginx.org/read.php?21,286846 in short, BoringSSL in 2017 has changed its behaviour related to TLS tickets: https://boringssl.googlesource.com/boringssl/+/72912d2 in short, it is ok if you specify TLS ticket key in file, and it simply does not work (i.e. works only for master process) if you do not specify. i.e. each process has its own TLS ticket key. and user has no way to choose web worker process. seems, it might be related to any multi process web server, not only nginx. are there some tests in haproxy to cover such boringssl behaviour ? > > > I would disable session tickets by default in haproxy. Given that most > > clients support TLS 1.3 already this change would not even slow down many > > clients. > > The problem is not as much the client slowing down as killing the servers > by the excess of handshakes caused by the minority of remaining clients, > because with this the service easily becomes totally unavailable for > everyone depending on the population of clients. Not everyone has a lot > of up-to-date browsers in their clients, and a number of deployments > actually never see a browser at all. > > Willy > >
Re: Clarification for ARM support
El lun., 9 mar. 2020 a las 15:52, Willy Tarreau () escribió: > On Mon, Mar 09, 2020 at 03:41:19PM +0200, Emilio Fernandes wrote: > > > I guess this was written before arm64 was really a thing, but both > 32bits > > > and 64bits arm are actively supported. > > > > > > > This is great to hear! > > Could you please update the website to mention this ? It would make > > managers more confident in using ARM based servers. > > Done, added "AARCH64" next to "ARM" to reflect this. But quite frankly > Awesome! Thank you! > if your managers are sensitive to this level of detail when deciding on > what technology to use, you should find another manager. > My managers are cool! I like them! :-) > > Willy >
Re: TLS tickets prone to MITM attacks (was: [PR] Docs tls tickets)
On Mon, Mar 09, 2020 at 07:18:23PM +0100, Björn Jacke wrote: > On 2020-03-09 at 17:44 +0100 Lukas Tribus sent off: > > Perhaps we can relax the wording a bit here and describe the actual > > technical issue along with some recommendations. Apache for example > > documents [1]: > > I think the wording from the patch is still quite relaxed :). One of the best > summaries describing the session ticket flaws, which I recommend is this: > https://blog.filippo.io/we-need-to-talk-about-session-tickets/ So as explained in the article above, all of this is only a problem if keys are *never* rotated. New keys are used every time the process is reloaded, and those using distributed deployments update them via the "set ssl tls-key" command on the CLI which purposely supports old and new key in order to maintain a distributed state synchronized yet up to date. > I would disable session tickets by default in haproxy. Given that most > clients support TLS 1.3 already this change would not even slow down many > clients. The problem is not as much the client slowing down as killing the servers by the excess of handshakes caused by the minority of remaining clients, because with this the service easily becomes totally unavailable for everyone depending on the population of clients. Not everyone has a lot of up-to-date browsers in their clients, and a number of deployments actually never see a browser at all. Willy
Re: TLS tickets prone to MITM attacks (was: [PR] Docs tls tickets)
On 2020-03-09 at 17:44 +0100 Lukas Tribus sent off: > Perhaps we can relax the wording a bit here and describe the actual > technical issue along with some recommendations. Apache for example > documents [1]: I think the wording from the patch is still quite relaxed :). One of the best summaries describing the session ticket flaws, which I recommend is this: https://blog.filippo.io/we-need-to-talk-about-session-tickets/ I would disable session tickets by default in haproxy. Given that most clients support TLS 1.3 already this change would not even slow down many clients. Björn
Re: [PATCH] SCRIPTS: Create -LATEST symlink for each BRANCH
Willy, Am 09.03.20 um 19:05 schrieb Willy Tarreau: > Then why don't use use the snapshots, which already contain a LATEST link ? > They're produced daily when there are changes, and they're even produced > for stable branches if that's of any interest. > >http://www.haproxy.org/download/2.2/src/snapshot/ for some reason I only saw the `-patches` tarball and missed / ignored the `-ss` one. I guess that'll work for me, thanks. Best regards Tim Düsterhus
Re: [PATCH] SCRIPTS: Create -LATEST symlink for each BRANCH
On Mon, Mar 09, 2020 at 06:00:42PM +0100, Tim Duesterhus wrote: > Willy, > > I wanted to add VTest tests to [haproxy-auth-request]. I'd like to test the > Lua script with various HAProxy branches and ideally run the test with the > latest patch version for each branch instead of hardcoding whatever was > recent when writing the tests. > > This does not appear to be easily possible right now, because there is no > real machine readable way to obtain that information to the best of my > knowledge. > > With this new symlinks I can simply download the -LATEST tarball and call > it a day. Then why don't use use the snapshots, which already contain a LATEST link ? They're produced daily when there are changes, and they're even produced for stable branches if that's of any interest. http://www.haproxy.org/download/2.2/src/snapshot/ Willy
[PATCH] SCRIPTS: Create -LATEST symlink for each BRANCH
Willy,
I wanted to add VTest tests to [haproxy-auth-request]. I'd like to test the
Lua script with various HAProxy branches and ideally run the test with the
latest patch version for each branch instead of hardcoding whatever was
recent when writing the tests.
This does not appear to be easily possible right now, because there is no
real machine readable way to obtain that information to the best of my
knowledge.
With this new symlinks I can simply download the -LATEST tarball and call
it a day.
The changes have *NOT* been tested. If you pick this change I'd appreciate
if you could create the necessary symlinks for HAProxy 1.8+.
[haproxy-auth-request]: https://github.com/TimWolla/haproxy-auth-request
Best regards
Tim Düsterhus
Apply with `git am --scissors` to automatically cut the commit message.
-- >8 --
This allows scripts, such as continous integration pipelines to easily grab
the latest patch version of a specific branch.
---
scripts/publish-release | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/scripts/publish-release b/scripts/publish-release
index 5a9a5cead..a353ba5d8 100755
--- a/scripts/publish-release
+++ b/scripts/publish-release
@@ -167,7 +167,10 @@ fi
( cd "$TARGET_DIR/src${DEVEL}" ; \
md5sum haproxy-$NEW.tar.gz > haproxy-$NEW.tar.gz.md5 ; \
- sha256sum haproxy-$NEW.tar.gz > haproxy-$NEW.tar.gz.sha256 )
+ sha256sum haproxy-$NEW.tar.gz > haproxy-$NEW.tar.gz.sha256 ; \
+ ln -fs haproxy-$NEW.tar.gz haproxy-${BRANCH}-LATEST.tar.gz ; \
+ ln -fs haproxy-$NEW.tar.gz.md5 haproxy-${BRANCH}-LATEST.tar.gz.md5 ; \
+ ln -fs haproxy-$NEW.tar.gz.sha256 haproxy-${BRANCH}-LATEST.tar.gz.sha256)
echo "Extracting doc ..."
git show "v$NEW:CHANGELOG" > "$TARGET_DIR/src/CHANGELOG"
@@ -179,6 +182,6 @@ done
echo "Done : ls -l ${TARGET_DIR}"
( cd "$TARGET_DIR" ;
- ls -l src/CHANGELOG "src${DEVEL}/haproxy-${NEW}".tar.gz{,.md5,.sha256} $(for
i in "${DOC[@]}"; do echo "doc/${i#doc/}"{,.gz}; done)
+ ls -l src/CHANGELOG "src${DEVEL}/haproxy-${NEW}".tar.gz{,.md5,.sha256}
"src${DEVEL}/haproxy-${BRANCH}-LATEST".tar.gz{,.md5,.sha256} $(for i in
"${DOC[@]}"; do echo "doc/${i#doc/}"{,.gz}; done)
)
echo
--
2.25.1
Re: TLS tickets prone to MITM attacks (was: [PR] Docs tls tickets)
Hi Lukas, On Mon, Mar 09, 2020 at 05:44:59PM +0100, Lukas Tribus wrote: > > + The TLS ticket mechanism is only used up to TLS 1.2 and it is prone to > > + man-in-the-middle attacks. You should consider to disable them for > > + security reasons. TLS 1.3 implements more secure methods for session > > + resumption. > > I know that this is already merged, but I disagree with the statements > regarding TLS-tickets, the reality is a bit more nuanced. > > What is true is that *PFS* could be compromised if the TLS ticket key > is not periodically rotated. That doesn't mean this configuration is > "prone to MITM attacks", that the actual SSL session is compromised or > that TLS tickets need to be disabled in every case. > > Perhaps we can relax the wording a bit here and describe the actual > technical issue along with some recommendations. Apache for example > documents [1]: > > > TLS session tickets are enabled by default. Using them without restarting > > the > > web server with an appropriate frequency (e.g. daily) compromises perfect > > forward secrecy. > > > and for a static TLS ticket file: > > > The ticket key file contains sensitive keying material and should be > > protected with file permissions similar to those used for > > SSLCertificateKeyFile. Thanks for reporting this. You definitely know better than me the impacts of all of this and I trust you to be able to rephrase something more suitable than what I could write. Please just send a patch to amend the current one and I'll happily merge it. Thanks! Willy
TLS tickets prone to MITM attacks (was: [PR] Docs tls tickets)
Hello, On Mon, 9 Mar 2020 at 11:23, PR Bot wrote: > > Dear list! > > Author: Björn Jacke > Number of patches: 2 > > This is an automated relay of the Github pull request: >Docs tls tickets > > Patch title(s): >BUG/MINOR: fix typo of tls-tickets >DOC: improve description of no-tls-tickets [...] > + The TLS ticket mechanism is only used up to TLS 1.2 and it is prone to > + man-in-the-middle attacks. You should consider to disable them for > + security reasons. TLS 1.3 implements more secure methods for session > + resumption. I know that this is already merged, but I disagree with the statements regarding TLS-tickets, the reality is a bit more nuanced. What is true is that *PFS* could be compromised if the TLS ticket key is not periodically rotated. That doesn't mean this configuration is "prone to MITM attacks", that the actual SSL session is compromised or that TLS tickets need to be disabled in every case. Perhaps we can relax the wording a bit here and describe the actual technical issue along with some recommendations. Apache for example documents [1]: > TLS session tickets are enabled by default. Using them without restarting the > web server with an appropriate frequency (e.g. daily) compromises perfect > forward secrecy. and for a static TLS ticket file: > The ticket key file contains sensitive keying material and should be > protected with file permissions similar to those used for > SSLCertificateKeyFile. Thanks, Lukas [1] https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslsessionticketkeyfile
Re: [PATCH 3/3] MEDIUM: proxy_protocol: Support sending unique IDs using PPv2
Willy, Am 06.03.20 um 13:15 schrieb Tim Duesterhus: > is acceptable. There's also a `BUG_ON` left in the patch, because I wasn't > sure if I should grab the session from the stream or from the connection. I just realized that BUG_ON is not active by default (should we add DEBUG_STRICT=1 to CI?). The check in there does not even compile (facepalm). In any case: I just fixed that build failure locally and can confirm that the BUG_ON does not trigger. Consider that line a "Please carefully check my assumptions, Willy". Best regards Tim Düsterhus
[PATCH] BUILD: Avoid warning about ignoring write()'s return value in BUG_ON()
gcc complains (non-rightfully):
> include/common/buf.h: In function ‘br_head_pick’:
> include/common/debug.h:62:4: warning: ignoring return value of ‘write’,
> declared with attribute warn_unused_result [-Wunused-result]
> (void)write(2, msg, strlen(msg)); \
> ^
> include/common/debug.h:57:35: note: in expansion of macro ‘__BUG_ON’
> #define _BUG_ON(cond, file, line) __BUG_ON(cond, file, line)
>^
> include/common/debug.h:56:22: note: in expansion of macro ‘_BUG_ON’
> #define BUG_ON(cond) _BUG_ON(cond, __FILE__, __LINE__)
> ^
> include/common/buf.h:1011:2: note: in expansion of macro ‘BUG_ON’
> BUG_ON(r->area != BUF_RING.area);
> ^
---
include/common/debug.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/common/debug.h b/include/common/debug.h
index df8552229..e748c9697 100644
--- a/include/common/debug.h
+++ b/include/common/debug.h
@@ -53,13 +53,14 @@
#define CRASH_NOW()
#endif
+extern int shut_your_big_mouth_gcc_int;
#define BUG_ON(cond) _BUG_ON(cond, __FILE__, __LINE__)
#define _BUG_ON(cond, file, line) __BUG_ON(cond, file, line)
#define __BUG_ON(cond, file, line)
\
do { \
if (unlikely(cond)) { \
const char msg[] = "\nFATAL: bug condition \"" #cond
"\" matched at " file ":" #line "\n"; \
- (void)write(2, msg, strlen(msg)); \
+ shut_your_big_mouth_gcc_int = write(2, msg,
strlen(msg)); \
CRASH_NOW(); \
} \
} while (0)
--
2.25.1
Re: Recommendations for deleting headers by regexp in 2.x?
Hello, +1 for this feature I have some rspidel and rspirep waiting to be migrated to 2.2 when this feature will be available. Thanks, El vie, 14-02-2020 a las 09:59 +0100, Willy Tarreau escribió: > Hi James, > > On Fri, Jan 31, 2020 at 12:44:24PM -0800, James Brown wrote: > > So how should we move this proposal forward? I'm glad to contribute > > more > > patches... > > Sorry for the very late response, we needed to discuss this with > Christopher then both got busy and then forgot :-/ > > So after discussion, we both agreed that it makes sense to implement > it > following the same model as the ACLs described below : > > > > A variant of this could be to use the same syntax as the options > > > we already > > > use on ACL matches, which are "-m reg", "-m beg", "-m end". But > > > these will > > > also need to be placed after to avoid the same ambiguity (since > > > "-m" is a > > > token hence a valid header name). That would give for example : > > > > > > http-request del-header server > > > http-request del-header x-private- -m beg > > > http-request del-header x-.*company -m reg > > > http-request del-header -tracea -m end > > However, do not feel pressured to implement all matching methods! The > currently known ones are described in section 7.1 of the doc, I think > that "str", "reg", "sub", "beg" and "end" are the only ones which > would > make sense over the long term. In practice we could have "str" being > the current one and "beg" being the one with the prefix as you need. > If later others need more modes we can implement them (unless you > want > to provide them all at once of course). > > Thanks for whatever you can do in this area and sorry again for > responding late! > > Willy >
[ANNOUNCE] haproxy-2.2-dev4
Hi, HAProxy 2.2-dev4 was released on 2020/03/09. It added 124 new commits after version 2.2-dev3. That's another round of updates and cleanups accumulated over the last two weeks. The updates mostly focused on 6 fronts this time: - ACL: the unique-id generation used to be extremely slow (O(n^2)) and take a lot of time to start when dealing with many ACL patterns. That was reworked by Carl Henrik Lunde and is now typically 100+ times faster. It will likely be backported to 2.0 once it has been shown not to cause any side effect. - Lua: Lua-declared actions can now yield, not in the Lua way but at least in the haproxy way, in that, just like other actions, they may signal they can't proceed and need to wait so that they are evaluated again later. In addition it is now possible to write filters in Lua so that it should require less ugly and unreliable tricks (don't ask me how however, I haven't looked yet). - SSL/CLI: dynamic update of certificates in crt-list used to be limited to those without filters. Now those involving filters can be updated as well using "set ssl cert". - random/UUID: we've got some insightful complaints that UUID were far from being unique in multi-process environments! And this is true, since the randoms were poorly seeded and were not re-seeded after the fork, due to the fact that randoms were only used to spread health checks in the past. In addition I discovered that most random() implementations were not even thread-safe. So we now have a pseudo- random number generator that's thread safe and which properly uses different seeds on different processes. This will be backported as far as 2.0 where UUID was backported. - polling: we still used to observe a performance degradation compared to 1.7 on the number of syscalls used per requests on a connection in keep-alive mode (there were several epollctl() calls per request). These were significantly improved now so that we can now have less calls by avoiding needlessly unregistering events. The difference is visible in extreme scenarios where there were thousands times more connections than run-queue-depth and these connections were experiencing frequent requests, like when using very interactive services. - watchdog: the watchdog that detects deadlocks and kills a runaway process used to depend both on Linux and threads. Now it also works on FreeBSD and/or when threads are disabled. It's important since there seems to be a fair number of users on FreeBSD, so we can now improve the reliability there as well. - backtraces: on operating systems where this is possible and relevant, when the watchdog triggers, a call trace will be produced in best effort. Till know we only used to know what task was running, this was a bit limited and a number of backtraces still couldn't be exploited without gdb and a core. Now at least on Linux/x86_64 and arm64 by default, and FreeBSD/x86_64 when compiled with USE_BACKTRACE=1 we'll get a detailed backtrace with function names+offsets and/or pointers. This should improve issue reports where known bugs will have more chances of being recognized and this might help developers understand the issue without bothering the reporter asking for a core dump. There's still quite some work to do before 2.2 (roughly 2.5 months ahead). If you still have secret patches on your side, it's the last moment before the window closes at the end of the month with dev5, after which only the ongoing stuff will be merged. I noticed Tim's extensions to pass unique IDs in PPv2 on the list, I'm also aware of some ongoing work on idle connections and SSL, and I remember that a few other less impacting points were discussed, such as syslog over TCP and a few adjustments to errorfile and return directives. Now let's beat it hard. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : http://www.haproxy.org/download/2.2/src/ Git repository : http://git.haproxy.org/git/haproxy.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy.git Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ Willy --- Complete changelog : Bjoern Jacke (1): DOC: fix typo about no-tls-tickets Björn Jacke (1): DOC: improve description of no-tls-tickets Carl Henrik Lunde (1): OPTIM: startup: fast unique_id allocation for acl. Christopher Faulet (30): MINOR: contrib/prometheus-exporter: Add the last heathcheck duration metric BUG/MINOR: http-htx: Do case-insensive comparisons on Host header name MINOR: mux-h1: Remove useless
Re: is hdr_ip compatible with ipv6 ?
Hi Ilya, > accidently I've found the following (I do not remember it on mailing list): > > https://github.com/haproxy/haproxy/compare/master...felixbuenemann:source-hdr_ip-ipv6-support > > Fix source usesrc hdr_ip() parsing for IPv6 > > The current parsing code for source usesrc hdr_ip() hardcodes the > assumption that the header will contain an IPv4 address. If it contains > an IPv6 address, a wrong IPv4 address will be generated from it. > > This fix checks if the header contains an IPv4 address, by checking if > it contains at least one dot, but no colons. Otherwise the address is > parsed as an IPv6 address. For me usesrc is used only in transparent mode, which (to the best of my knowledge) doesn't work in IPv6. But I could be wrong. Willy
Re: Clarification for ARM support
On Mon, Mar 09, 2020 at 03:41:19PM +0200, Emilio Fernandes wrote: > > I guess this was written before arm64 was really a thing, but both 32bits > > and 64bits arm are actively supported. > > > > This is great to hear! > Could you please update the website to mention this ? It would make > managers more confident in using ARM based servers. Done, added "AARCH64" next to "ARM" to reflect this. But quite frankly if your managers are sensitive to this level of detail when deciding on what technology to use, you should find another manager. Willy
Re: [PR] Docs tls tickets
On Mon, Mar 09, 2020 at 11:23:10AM +0100, PR Bot wrote: > Author: Björn Jacke > Number of patches: 2 > > This is an automated relay of the Github pull request: >Docs tls tickets > > Patch title(s): >BUG/MINOR: fix typo of tls-tickets >DOC: improve description of no-tls-tickets (...) Looks fine, now merged, thanks! Willy
Re: [PATCH] CLEANUP: remove unused code in 'my_ffsl/my_flsl' functions
On Sun, Mar 08, 2020 at 04:38:38PM +0100, Miroslav Zagorac wrote: > It seems to me that shifting the variable 'a' at the end of the functions is > of no use. Maybe there is something I don't see here, in which case I > apologize. :) You're right. It was mostly a matter of consistency, and anyway the compiler doesn't emit the code for it. But we can remove it. Applied, thanks Miroslav! Willy
Re: [PATCH] 3rd round of documentation typo fixes
On Fri, Mar 06, 2020 at 11:25:23PM +0500, ??? wrote: > Hello, > > I attached a patch based on documentation spelcheck. Applied, thanks Ilya! Willy
Re: Clarification for ARM support
Hi Olivier, El lun., 9 mar. 2020 a las 12:58, Olivier Houchard () escribió: > Hi, > > On Mon, Mar 09, 2020 at 10:33:55AM +0200, Emilio Fernandes wrote: > > Hello HAProxy team, > > > > At https://www.haproxy.org/#plat I see that ARM architecture is > supported > > for Linux with newer kernel. > > To avoid confusion could you please add next to it whether it is only 32 > > bit, 64 bit or both ? Just like "x86, x86_64" before that. > > > > Recently we started testing on ARM64 and so far it works great! Great > job! > > Thank you! > > > > I guess this was written before arm64 was really a thing, but both 32bits > and 64bits arm are actively supported. > This is great to hear! Could you please update the website to mention this ? It would make managers more confident in using ARM based servers. I could also provide a Pull Request / patch if the website source is available in some repository! Thank you! Emilio > Regards, > > Olivier >
Re: Clarification for ARM support
Hi, On Mon, Mar 09, 2020 at 10:33:55AM +0200, Emilio Fernandes wrote: > Hello HAProxy team, > > At https://www.haproxy.org/#plat I see that ARM architecture is supported > for Linux with newer kernel. > To avoid confusion could you please add next to it whether it is only 32 > bit, 64 bit or both ? Just like "x86, x86_64" before that. > > Recently we started testing on ARM64 and so far it works great! Great job! > Thank you! > I guess this was written before arm64 was really a thing, but both 32bits and 64bits arm are actively supported. Regards, Olivier
[PR] Docs tls tickets
Dear list! Author: Björn Jacke Number of patches: 2 This is an automated relay of the Github pull request: Docs tls tickets Patch title(s): BUG/MINOR: fix typo of tls-tickets DOC: improve description of no-tls-tickets Link: https://github.com/haproxy/haproxy/pull/537 Edit locally: wget https://github.com/haproxy/haproxy/pull/537.patch && vi 537.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/537.patch | git am - Description: typo in parameter and description improvement Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
Clarification for ARM support
Hello HAProxy team, At https://www.haproxy.org/#plat I see that ARM architecture is supported for Linux with newer kernel. To avoid confusion could you please add next to it whether it is only 32 bit, 64 bit or both ? Just like "x86, x86_64" before that. Recently we started testing on ARM64 and so far it works great! Great job! Thank you! Emilio
