I could be wrong, but I think he is stating that if you have that
allowed, it can be used to get a direct connection to the backend
bypassing any routing or acls you have in the load balancer, so if you
some endpoints are blocked, or internal only, they could potentially
be accessed this way.
For e
Hi Willy,
Being devil's advocate : isn't the point that even if this is a documented,
standardized and intended behavior, users relying on the reverse proxy for
security/sanity checks could by tricked by this feature inadvertently ?
--
Ionel GARDAIS
Tech'Advantage CIO - IT Team manager
-
On Fri, Sep 11, 2020 at 08:07:02AM +0200, Willy Tarreau wrote:
> Sadly, as usual after people discover protocols during the summer, some
> journalists will surely want to make noise about this to put some bread
> on their table...
>
> Thanks for the link anyway I had a partial laugh; partial only
Hi Igor,
On Fri, Sep 11, 2020 at 01:55:10PM +1000, Igor Cicimov wrote:
> Should we be worried?
>
> https://portswigger.net/daily-swig/http-request-smuggling-http-2-opens-a-new-attack-tunnel
But this stuff is total non-sense. Basically the guy is complaining
that the products he tested work exact
On Thu, Sep 10, 2020 at 07:46:37PM +0200, Tim Duesterhus wrote:
> Willy,
>
> this basically is a continuation from my series in July:
>
> https://www.mail-archive.com/haproxy@formilux.org/msg37808.html
>
> One more real bugfix and 4 more frees of live allocations for consistency with
> the surro
Should we be worried?
https://portswigger.net/daily-swig/http-request-smuggling-http-2-opens-a-new-attack-tunnel
IC
This allocation is technically always reachable and cannot leak, but so are
a few others that *are* freed.
---
src/haproxy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/haproxy.c b/src/haproxy.c
index 0dc81c78c..e70870ab0 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2407,6
This allocation is technically always reachable and cannot leak, but so are
a few others that *are* freed.
---
src/haproxy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/haproxy.c b/src/haproxy.c
index 663922e72..b01707096 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2403,6
Given the following example configuration:
listen http
bind *:80
mode http
stats scope .
Running a configuration check with valgrind reports:
==16341== 26 (24 direct, 2 indirect) bytes in 1 blocks are definitely lost
in loss record 3 of 13
==16341==at 0x4
This allocation technically is always reachable and cannot leak, however other
global variables such as `oldpids` are already being freed. This is in an
attempt to get HAProxy to a state where there are zero live allocations after a
clean exit.
---
src/haproxy.c | 1 +
1 file changed, 1 insertion(
This allocation is technically always reachable and cannot leak, but so are
a few others that *are* freed.
---
src/haproxy.c | 24
1 file changed, 24 insertions(+)
diff --git a/src/haproxy.c b/src/haproxy.c
index b01707096..0dc81c78c 100644
--- a/src/haproxy.c
+++ b/src/h
Willy,
this basically is a continuation from my series in July:
https://www.mail-archive.com/haproxy@formilux.org/msg37808.html
One more real bugfix and 4 more frees of live allocations for consistency with
the surrounding code.
Best regards
Tim Düsterhus (5):
BUG/MINOR: haproxy: Free uri_au
Hi Ilya,
On Thu, Sep 10, 2020 at 09:45:08PM +0500, ??? wrote:
> ping :)
Ah sorry, thanks for the reminedr, I remember reading it and thought it
was merged, but I was wrong. However I'm seeing two mistakes:
- first patch accidently merged a copy of your libwurfl.a. Don't
worry, I'l
ping :)
вс, 6 сент. 2020 г. в 13:40, Илья Шипицин :
> Hello,
>
> based on discussion https://github.com/haproxy/haproxy/issues/755
>
> cheers,
> Ilya Shipitcin
>
Thanks Bruno,
I'll see if I can get this working.
--
Kevin
On 2020-09-09 9:41 p.m., Bruno Henc wrote:
Hi,
I take it that means theres no internal debug logging for the tls
errors that we can just expose via logfile?
Proof of concept patches are attached with build instructions. You may
15 matches
Mail list logo