Quick question for haproxy.org

[Charolette Danzig]

Hi there,

I realise you're busy so I'll get straight to the point. I noticed that in your 
article www.haproxy.org/they-use-it.html you linked to vpnroom.com/.

I've got a couple of clients who are interested in getting in on the action - 
how much do you charge for a placement like that?

Best,
Charolette Danzig
ps - if you're not the right person to talk to about this, who should I be 
talking to?
pps - just hit me up with a quick 'unsubscribe' if you don't want to receive 
any more advertising opportunities from me

Re: CVE-2023-44487 and haproxy-1.8

[Willy Tarreau]

On Mon, Oct 16, 2023 at 08:33:51PM +0200, Aleksandar Lazic wrote:
> 
> On 2023-10-16 (Mo.) 20:12, Lukas Tribus wrote:
> > On Mon, 16 Oct 2023 at 19:41, Aleksandar Lazic  wrote:
> > > 
> > > 
> > > 
> > > On 2023-10-16 (Mo.) 19:29,  ??? wrote:
> > > > Does 1.8 support http/2?
> > > 
> > > No.
> > 
> > Actually haproxy 1.8 supports H2 (without implementing HTX), as per
> > the documentation and announcements:
> > 
> > https://www.mail-archive.com/haproxy@formilux.org/msg28004.html
> > http://docs.haproxy.org/1.8/configuration.html#5.1-alpn
> > 
> > 
> > It does so by downgrading H2 to HTTP/1.1.
> > 
> > 
> > I don't know whether haproxy 1.8 actually is affected by the rapid
> > reset vulnerability or not. I suppose it's possible.
> 
> Well as far as I have understood the attack in a proper way, is the request
> in HTTP/2 mode and stay in that Mode, which isn't the case in 1.8. As you
> already mentioned was in 1.8 the HTTP/2 request "converted" into HTTP/1 and
> 1.9 is the first version which supports end2end HTTP/2.

As Lukas said, in 1.8 H2 is transcoded to HTTP/1.1. It was the very
first implementation. The architecture was different (and overly
complicated due to the limited abilities by then). Most H2 events
would make synchronous calls to the upper layers which would in turn
make synchronous calls downwards. The RST_STREAM does call a ->recv()
and a ->wake() callbacks. It could be possible that due to this, by
chance it was not affected but that would be pure luck, not a design
decision. I'll need to run some tests on it to know.

Quite frankly, given the numerous limitations of H2 in 1.8, I strongly
doubt anyone interested in H2 uses it on 1.8, so if it were to be
affected and if a trivial fix couldn't be figured, suggesting to disable
it could remain a sane option.

Regards,
Willy

Re: CVE-2023-44487 and haproxy-1.8

[Aleksandar Lazic]

On 2023-10-16 (Mo.) 20:12, Lukas Tribus wrote:

On Mon, 16 Oct 2023 at 19:41, Aleksandar Lazic  wrote:




On 2023-10-16 (Mo.) 19:29, Илья Шипицин wrote:

Does 1.8 support http/2?


No.


Actually haproxy 1.8 supports H2 (without implementing HTX), as per
the documentation and announcements:

https://www.mail-archive.com/haproxy@formilux.org/msg28004.html
http://docs.haproxy.org/1.8/configuration.html#5.1-alpn


It does so by downgrading H2 to HTTP/1.1.


I don't know whether haproxy 1.8 actually is affected by the rapid
reset vulnerability or not. I suppose it's possible.


Well as far as I have understood the attack in a proper way, is the 
request in HTTP/2 mode and stay in that Mode, which isn't the case in 
1.8. As you already mentioned was in 1.8 the HTTP/2 request "converted" 
into HTTP/1 and 1.9 is the first version which supports end2end HTTP/2.


To be more precise here the quote from above announcement

```

  - HTTP/2 will not schedule a graceful connection shutdown anymore when
seeing a "Connection: close" header in a response. Instead a new HTTP
action "reject" has been implemented to work like its TCP counter-part.
```

This implies that the connection does not stay open and the attack could 
not work.

But maybe there is a better explanation why 1.8 is not affected.


Lukas


Regards
Alex

Re: CVE-2023-44487 and haproxy-1.8

[Aleksandar Lazic]

Hi .

On 2023-10-16 (Mo.) 19:55, Ryan O'Hara wrote:
I wondered exactly the same thing, but then saw this on the haproxy.org 
website:


"version 1.8 : multi-threading, HTTP/2, cache, on-the fly server 
addition/removal, seamless reloads, DNS SRV, hardware SSL engines, ..."


I know that haproxy-1.9 added end-to-end HTTP/2, so is that the 
determining factor? here? Many thanks.


Oh you are right. The 1.8 was the first one with the mux_h2.c in the 
tree. This was the first version with some first steps into HTTP/2 
world. From my point of view are the Statements from the HAProxy.com 
blog quite accurate why 1.8 is not affected with that CVE.



Ryan


Regards
Alex

On Mon, Oct 16, 2023 at 12:41 PM Aleksandar Lazic > wrote:




On 2023-10-16 (Mo.) 19:29, Илья Шипицин wrote:
 > Does 1.8 support http/2?

No.

 > On Mon, Oct 16, 2023, 18:58 Ryan O'Hara mailto:roh...@redhat.com>
 > >> wrote:
 >
 >     Hi all.
 >
 >     I read the most recently HAProxy Newsletter, specifically the
 >     article "HAProxy is Not Affected by the HTTP/2 Rapid Reset
Attack"
 >     by Nick Ramirez [1]. A This article states that HAProxy
versions 1.9
 >     and later are *not* affetced, which is great. This implies that
 >     haproxy-1.8 *is* affected, but it also doesn't come right out and
 >     say that. I understand haproxy-1.8 is EOL, but do we know for
 >     certain that haproxy-1.8 is affected or not? Asking for a reason.
 >
 >     And shout-out to Nick for writing such a great article! Thank
you, Nick!
 >
 >     Ryan
 >
 >     [1]
 >

https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
 

 
>
 >

Re: CVE-2023-44487 and haproxy-1.8

[Lukas Tribus]

On Mon, 16 Oct 2023 at 19:41, Aleksandar Lazic  wrote:
>
>
>
> On 2023-10-16 (Mo.) 19:29, Илья Шипицин wrote:
> > Does 1.8 support http/2?
>
> No.

Actually haproxy 1.8 supports H2 (without implementing HTX), as per
the documentation and announcements:

https://www.mail-archive.com/haproxy@formilux.org/msg28004.html
http://docs.haproxy.org/1.8/configuration.html#5.1-alpn


It does so by downgrading H2 to HTTP/1.1.


I don't know whether haproxy 1.8 actually is affected by the rapid
reset vulnerability or not. I suppose it's possible.

Lukas

Re: CVE-2023-44487 and haproxy-1.8

[Ryan O'Hara]

I wondered exactly the same thing, but then saw this on the haproxy.org
website:

"version 1.8 : multi-threading, HTTP/2, cache, on-the fly server
addition/removal,
seamless reloads, DNS SRV, hardware SSL engines, ..."

I know that haproxy-1.9 added end-to-end HTTP/2, so is that the
determining factor? here? Many thanks.

Ryan




On Mon, Oct 16, 2023 at 12:41 PM Aleksandar Lazic 
wrote:

>
>
> On 2023-10-16 (Mo.) 19:29, Илья Шипицин wrote:
> > Does 1.8 support http/2?
>
> No.
>
> > On Mon, Oct 16, 2023, 18:58 Ryan O'Hara  > > wrote:
> >
> > Hi all.
> >
> > I read the most recently HAProxy Newsletter, specifically the
> > article "HAProxy is Not Affected by the HTTP/2 Rapid Reset Attack"
> > by Nick Ramirez [1]. A This article states that HAProxy versions 1.9
> > and later are *not* affetced, which is great. This implies that
> > haproxy-1.8 *is* affected, but it also doesn't come right out and
> > say that. I understand haproxy-1.8 is EOL, but do we know for
> > certain that haproxy-1.8 is affected or not? Asking for a reason.
> >
> > And shout-out to Nick for writing such a great article! Thank you,
> Nick!
> >
> > Ryan
> >
> > [1]
> >
> https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
> <
> https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
> >
> >
>
>

Re: CVE-2023-44487 and haproxy-1.8

[Aleksandar Lazic]

On 2023-10-16 (Mo.) 19:29, Илья Шипицин wrote:

Does 1.8 support http/2?


No.

On Mon, Oct 16, 2023, 18:58 Ryan O'Hara > wrote:


Hi all.

I read the most recently HAProxy Newsletter, specifically the
article "HAProxy is Not Affected by the HTTP/2 Rapid Reset Attack"
by Nick Ramirez [1]. A This article states that HAProxy versions 1.9
and later are *not* affetced, which is great. This implies that
haproxy-1.8 *is* affected, but it also doesn't come right out and
say that. I understand haproxy-1.8 is EOL, but do we know for
certain that haproxy-1.8 is affected or not? Asking for a reason.

And shout-out to Nick for writing such a great article! Thank you, Nick!

Ryan

[1]

https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
 

Re: CVE-2023-44487 and haproxy-1.8

[Илья Шипицин]

Does 1.8 support http/2?

On Mon, Oct 16, 2023, 18:58 Ryan O'Hara  wrote:

> Hi all.
>
> I read the most recently HAProxy Newsletter, specifically the article "HAProxy
> is Not Affected by the HTTP/2 Rapid Reset Attack" by Nick Ramirez [1]. A
> This article states that HAProxy versions 1.9 and later are *not* affetced,
> which is great. This implies that haproxy-1.8 *is* affected, but it also
> doesn't come right out and say that. I understand haproxy-1.8 is EOL, but
> do we know for certain that haproxy-1.8 is affected or not? Asking for a
> reason.
>
> And shout-out to Nick for writing such a great article! Thank you, Nick!
>
> Ryan
>
> [1]
> https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487
>

Re: CVE-2023-44487 and haproxy-1.8

[Aleksandar Lazic]

Hi Ryan.

On 2023-10-16 (Mo.) 17:49, Ryan O'Hara wrote:

Hi all.

I read the most recently HAProxy Newsletter, specifically the article 
"HAProxy is Not Affected by the HTTP/2 Rapid Reset Attack" by Nick 
Ramirez [1]. A This article states that HAProxy versions 1.9 and later 
are *not* affetced, which is great. This implies that haproxy-1.8 *is* 
affected, but it also doesn't come right out and say that. I understand 
haproxy-1.8 is EOL, but do we know for certain that haproxy-1.8 is 
affected or not? Asking for a reason.


Well HTX, which was the transition to HTTP/2, was implemented in 1.9 
which is the reason why 1.8 is not affected.


https://www.haproxy.com/blog/haproxy-1-9-has-arrived


And shout-out to Nick for writing such a great article! Thank you, Nick!

Ryan


Regards
Alex

[1] 
https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487

CVE-2023-44487 and haproxy-1.8

[Ryan O'Hara]

Hi all.

I read the most recently HAProxy Newsletter, specifically the article "HAProxy
is Not Affected by the HTTP/2 Rapid Reset Attack" by Nick Ramirez [1]. A
This article states that HAProxy versions 1.9 and later are *not* affetced,
which is great. This implies that haproxy-1.8 *is* affected, but it also
doesn't come right out and say that. I understand haproxy-1.8 is EOL, but
do we know for certain that haproxy-1.8 is affected or not? Asking for a
reason.

And shout-out to Nick for writing such a great article! Thank you, Nick!

Ryan

[1]
https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487

[PATCH] MINOR: support for http-response set-timeout

[Vladimir Vdovin]

Added set-timeout action for http-response. Adapted reg-tests and
documentation.
---
 doc/configuration.txt  | 19 +
 reg-tests/http-set-timeout/set_timeout.vtc | 90 +-
 src/http_act.c |  1 +
 3 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 0b74ae291..88a576795 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -8087,6 +8087,7 @@ http-response   [ { if | unless } 
 ]
 - set-mark 
 - set-nice 
 - set-status  [reason ]
+- set-timeout { client | server | tunnel } {  |  }
 - set-tos 
 - set-var([,...]) 
 - set-var-fmt([,...]) 
@@ -8332,6 +8333,24 @@ http-response set-status  [reason ]
 # return "503 Slow Down", custom reason
 http-response set-status 503 reason "Slow Down".
 
+http-response set-timeout { client | server | tunnel } {  |  }
+   [ { if | unless }  ]
+
+  This action overrides the specified "client", "server" or "tunnel" timeout 
for the
+  current stream only. The timeout can be specified in millisecond or with any
+  other unit if the number is suffixed by the unit as explained at the top of
+  this document. It is also possible to write an expression which must returns
+  a number interpreted as a timeout in millisecond.
+
+  Note that the server/tunnel timeouts are only relevant on the backend side
+  and thus this rule is only available for the proxies with backend
+  capabilities. As well as client timeout is only relevant for frontend side.
+  Also the timeout value must be non-null to obtain the expected results.
+
+  Example:
+http-response set-timeout tunnel 5s
+http-response set-timeout server res.hdr(X-Refresh-Seconds),mul(1000)
+
 http-response set-tos  [ { if | unless }  ]
 
   This is used to set the TOS or DSCP field value of packets sent to the client
diff --git a/reg-tests/http-set-timeout/set_timeout.vtc 
b/reg-tests/http-set-timeout/set_timeout.vtc
index 6fa0a35f1..a112bc51e 100644
--- a/reg-tests/http-set-timeout/set_timeout.vtc
+++ b/reg-tests/http-set-timeout/set_timeout.vtc
@@ -4,7 +4,7 @@ feature ignore_unknown_macro
 
 #REQUIRE_VERSION=2.4
 
-server srv_h1 -repeat 5 {
+server srv_h1 -repeat 9 {
 rxreq
 txresp
 } -start
@@ -34,6 +34,26 @@ syslog Slog5 -level info {
 expect ~ "^.*timeout: 5000 3000.*$"
 } -start
 
+syslog Slog6 -level info {
+recv
+expect ~ "^.*timeout: 5000 5000.*$"
+} -start
+
+syslog Slog7 -level info {
+recv
+expect ~ "^.*timeout: 5000 5000.*$"
+} -start
+
+syslog Slog8 -level info {
+recv
+expect ~ "^.*timeout: 5000 3000.*$"
+} -start
+
+syslog Slog9 -level info {
+recv
+expect ~ "^.*timeout: 5000 3000.*$"
+} -start
+
 haproxy hap -conf {
 defaults
 timeout connect 5s
@@ -87,6 +107,46 @@ haproxy hap -conf {
 backend be2
mode http
server srv_h1 ${srv_h1_addr}:${srv_h1_port}
+
+listen li4
+mode http
+bind "fd@${li4}"
+log-format "timeout: %[be_server_timeout] %[cur_server_timeout]"
+log ${Slog6_addr}:${Slog6_port} len 2048 local0 debug err
+http-response set-timeout server 5s
+   server srv_h1 ${srv_h1_addr}:${srv_h1_port}
+
+listen li5
+mode http
+bind "fd@${li5}"
+log-format "timeout: %[fe_client_timeout] %[cur_client_timeout]"
+log ${Slog7_addr}:${Slog7_port} len 2048 local0 debug err
+http-response set-timeout client 5s
+   server srv_h1 ${srv_h1_addr}:${srv_h1_port}
+
+frontend fe3
+mode http
+bind "fd@${fe3}"
+log-format "timeout: %[be_server_timeout] %[cur_server_timeout]"
+log ${Slog8_addr}:${Slog8_port} len 2048 local0 debug err
+default_backend be1
+
+backend be3
+   mode http
+   http-response set-timeout server int(3),mul(1000)
+   server srv_h1 ${srv_h1_addr}:${srv_h1_port}
+
+frontend fe4
+mode http
+bind "fd@${fe4}"
+log-format "timeout: %[fe_client_timeout] %[cur_client_timeout]"
+log ${Slog9_addr}:${Slog9_port} len 2048 local0 debug err
+http-response set-timeout client int(3),mul(1000)
+default_backend be2
+
+backend be4
+   mode http
+   server srv_h1 ${srv_h1_addr}:${srv_h1_port}
 } -start
 
 client c1 -connect ${hap_li1_sock} {
@@ -119,8 +179,36 @@ client c5 -connect ${hap_fe2_sock} {
 expect resp.status == 200
 } -run
 
+client c6 -connect ${hap_li4_sock} {
+txreq
+rxresp
+expect resp.status == 200
+} -run
+
+client c7 -connect ${hap_fe3_sock} {
+txreq
+rxresp
+expect resp.status == 200
+} -run
+
+client c8 -connect ${hap_li5_sock} {
+txreq
+rxresp
+expect resp.status == 200
+} -run
+
+client c9 -connect ${hap_fe4_sock} {
+txreq
+rxresp
+expect resp.status == 200
+} -run
+
 syslog Slog1 -wait
 syslog Slog2 -wait
 syslog Slog3 -wait
 syslog Slog4 -wait
 syslog 

Re: [PATCH] MINOR: support for http-response set-timeout

[Vladimir]

Sure, you are right. Sending little fix.

> 16 окт. 2023 г., в 09:21, Willy Tarreau  написал(а):
> 
> Hi Vladimir,
> 
> On Sun, Oct 15, 2023 at 06:00:01AM +0300, Vladimir Vdovin wrote:
>> Added set-timeout action for http-response. Adapted reg-tests and
>> documentation.
> 
> Thanks for this. At first glance it looks good. I'm just seeing one small
> nit in the doc:
> 
>> +http-response set-timeout { client | server | tunnel } {  |  
>> }
>> +   [ { if | unless }  ]
>> +
>> +  This action overrides the specified "client", "server" or "tunnel" 
>> timeout for the
>> +  current stream only. The timeout can be specified in millisecond or with 
>> any
>> +  other unit if the number is suffixed by the unit as explained at the top 
>> of
>> +  this document. It is also possible to write an expression which must 
>> returns
>> +  a number interpreted as a timeout in millisecond.
>> +
>> +  Note that the server/tunnel timeouts are only relevant on the backend side
>> +  and thus this rule is only available for the proxies with backend
>> +  capabilities. As well as client timeout is only relevant for frontend 
>> side.
>> +  Also the timeout value must be non-null to obtain the expected results.
>> +
>> +  Example:
>> +http-response set-timeout tunnel 5s
>> +http-response set-timeout server req.hdr(host),map_int(host.lst)
> 
> This last one will not work due to using req.hdr() which is only on
> the request path and not the response. Let's use something else, for
> example a header set by the server to indicate how many seconds to
> wait (as an example, any better idea is welcome):
> 
>   http-response set-timeout server res.hdr(X-Refresh-Seconds),mul(1000)
> 
> Thanks!
> Willy

Re: FYI: OpenWrt switches from wolfssl to mbedtls as default

[William Lallemand]

On Fri, Oct 13, 2023 at 04:30:37PM +0200, William Lallemand wrote:
> > and TLSv1.3 is a must-have,
> 
> I don't get this point, mbedtls supports TLS 1.3 so I don't really
> understand what they are talking about. Maybe they disable TLS 1.3 on
> the 2.28 version for some rease but I couldn't find any detail.
> 
>

Regarding this, I found in the changelog that mbedtls provides a minimum
viable implementation of the TLS 1.3 protocol starting from the 3.1.0
version, so it explains everything.

https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.1.0
> Mbed TLS provides a minimum viable implementation of the TLS 1.3
> protocol. See docs/architecture/tls13-support.md for the definition of
> the TLS 1.3 Minimum Viable Product (MVP). The MBEDTLS_SSL_PROTO_TLS1_3
> configuration option controls the enablement of the support. The APIs
> mbedtls_ssl_conf_min_version() and mbedtls_ssl_conf_max_version() allow
> to select the 1.3 version of the protocol to establish a TLS connection.
> 



-- 
William Lallemand

Re: [PATCH] MINOR: support for http-response set-timeout

[Willy Tarreau]

Hi Vladimir,

On Sun, Oct 15, 2023 at 06:00:01AM +0300, Vladimir Vdovin wrote:
> Added set-timeout action for http-response. Adapted reg-tests and
> documentation.

Thanks for this. At first glance it looks good. I'm just seeing one small
nit in the doc:

> +http-response set-timeout { client | server | tunnel } {  |  }
> +   [ { if | unless }  ]
> +
> +  This action overrides the specified "client", "server" or "tunnel" timeout 
> for the
> +  current stream only. The timeout can be specified in millisecond or with 
> any
> +  other unit if the number is suffixed by the unit as explained at the top of
> +  this document. It is also possible to write an expression which must 
> returns
> +  a number interpreted as a timeout in millisecond.
> +
> +  Note that the server/tunnel timeouts are only relevant on the backend side
> +  and thus this rule is only available for the proxies with backend
> +  capabilities. As well as client timeout is only relevant for frontend side.
> +  Also the timeout value must be non-null to obtain the expected results.
> +
> +  Example:
> +http-response set-timeout tunnel 5s
> +http-response set-timeout server req.hdr(host),map_int(host.lst)

This last one will not work due to using req.hdr() which is only on
the request path and not the response. Let's use something else, for
example a header set by the server to indicate how many seconds to
wait (as an example, any better idea is welcome):

   http-response set-timeout server res.hdr(X-Refresh-Seconds),mul(1000)

Thanks!
Willy