Proof of concept SPOE based SSO solution

[Andrew Heberle]

Hi All,

I have put together a Go based proof of concept SPOE agent that also
implements a SAML 2 Service Provider (SP) in order to do "SSO" in
HAProxy.

The code is located here:

https://gitlab.com/andrewheberle/go-http-auth-sso

The basic process is that SPOA is used to check if the user is logged
in or not and then based on the set variables you can make decisions
via "http-request" rules.

This originally started out without the SPOE part and was using the
Lua http-auth-request script
(https://github.com/TimWolla/haproxy-auth-request), however with the
release of the Go SPOE package
(https://github.com/Aestek/haproxy-connect/tree/master/spoe) I rewrote
it based on that.

Our use case is to have the SP pointed to a IdP in Azure so we can do
single-sign-on to Office 365 and we have "http-request" rules in place
to set some custom headers that our application uses for
authentication/authorisation.  These are set based on the variables
that come back from the SPOA, which come from the claims in the
authentication process.

Hopefully this is of some use to people.

Any feedback and constructive criticism is welcome.

-- 
Andrew Heberle

Re: Error with AddressSanitizer

[flamesea12]

Thank you, it solves the problem!

 - Original Message -
 From: Илья Шипицин 
 To: flamese...@yahoo.co.jp 
Cc: "haproxy@formilux.org" 
 Date: 2019/7/5, Fri 00:44
 Subject: Re: Error with AddressSanitizer
   
did you also use USE_OBSOLETE_LINKER=1 ?asan is supposed to be used together 
with obsolete linking

чт, 4 июл. 2019 г. в 19:14, :

Hi

I got this error when trying to debug a problem in haproxy

compile haproxy using clang with -fsanitize=address and start haproxy:


=
==27669==ERROR: AddressSanitizer: global-buffer-overflow on address 
0x019795c8 at pc 0xb28240 bp 0x7ffd7682c2d0 sp 0x7ffd7682c2c8
READ of size 8 at 0x019795c8 thread T0
    #0 0xb2823f in main src/haproxy.c:2710
    #1 0x7fb34cee8444 in __libc_start_main 
/usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274
    #2 0x49299c in _start (haproxy+0x49299c)

0x019795c8 is located 56 bytes to the left of global variable 
'__initcb_509' from 'src/task.c' (0x1979600) of size 8
0x019795c8 is located 0 bytes to the right of global variable 
'__initcb_1860' from 'src/log.c' (0x19795c0) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow src/haproxy.c:2710 main
Shadow bytes around the buggy address:
  0x80327260: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x80327270: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x80327280: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x80327290: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x803272a0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
=>0x803272b0: 00 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9 f9 f9 f9 f9
  0x803272c0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x803272d0: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x803272e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x803272f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80327300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==27669==ABORTING





   

Re: [RFC PATCH] BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2

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

can you provide some comment around code ?

I think almost nobody can read such code

чт, 4 июл. 2019 г. в 21:17, Emmanuel Hocdet :

> Hi,
>
> This thread reminds me that with BoringSSL empty (and abort) handshake is
> not set.
> After tests BoringSSL seems to have simpler case.
> I sent a patch to fix that.
>
> For OpenSSL <= 1.0.2, revert is the thing to do.
> For LibreSSL, include it with BoringSSL case could be ok (with my patch).
> With time (no HB and better error report in libSSL), it seems code could
> simply look like:
>   *if* (!errno)
>   conn->err_code = CO_ER_SSL_EMPTY;
>   *else*
>   conn->err_code = CO_ER_SSL_ABORT;
>
> ++
> Manu
>
> Le 4 juil. 2019 à 12:14, Lukas Tribus  a écrit :
>
> Hello Ilya,
>
>
> On Mon, 1 Jul 2019 at 23:08, Илья Шипицин  wrote:
>
>
>
>
> вт, 2 июл. 2019 г. в 01:34, Willy Tarreau :
>
>
> On Mon, Jul 01, 2019 at 10:32:29PM +0200, Lukas Tribus wrote:
>
> Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including")
> changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL,
> from accessing packet_length directly (not available in LibreSSL) to
> calling SSL_state() instead.
>
> (...)
>
> Thanks a lot Lukas. Just out of curiosity, do you have any idea of a
> concrete user-visible issue this bug can cause ? It would help bisecting
> issues later. I don't know in what case an empty handshake may happen.
>
>
>
> nmap scan ?
>
>
> Ilya, just to avoid misunderstandings, I would like to have your
> feedback on this patch so we can decide whether to commit it or work
> on counter-proposals.
>
>
> Thanks,
> Lukas
>
>
>

Re: Get http connection client/server ip/port

[Jarno Huuskonen]

Hi,

On Thu, Jul 04, Peter Hudec wrote:
> I have maybe found some bug in haproxy, submitted as 
> https://github.com/haproxy/haproxy/issues/154.

1.8.4 is fairly old, can you reproduce on more recent 1.8.x or latest 2.0.x ?

> The variables dst, dst_port are identical with the src, src_port.
> 
> Is there any other way how to get these /in this case dst/ values ??
> 
> What do I need is ..
> 
> http-request set-header X-Server-IP %[dst]
> http-request set-header X-Server-Port %[dst_port]
> http-request set-header X-Client-IP %[src]
> http-request set-header X-Client-Port %[src_port]
> 
> result is ;(
> 
>   'HTTP_X_CLIENT_PORT' => '22696',
>   'HTTP_X_CLIENT_IP' => '217.73.20.190',
>   'HTTP_X_SERVER_PORT' => '22696',
>   'HTTP_X_SERVER_IP' => '217.73.20.190’,

With this simple test config dst, dst_port etc. seem to work for me, does
this config work for you ?

global
stats socket /tmp/stats level admin

defaults
mode http
log global
option httplog

frontend test
bind :8080

default_backend test_be

backend test_be
http-request set-header X-Server-IP %[dst]
http-request set-header X-Server-Port %[dst_port]
http-request set-header X-Client-IP %[src]
http-request set-header X-Client-Port %[src_port]

server srv1 127.0.0.1:9000 id 1

listen yeah
bind ipv4@127.0.0.1:9000
http-request deny deny_status 200

run with for example haproxy -d -f tmp.conf and
curl http://127.0.0.1:8080 and you should see the headers from haproxy debug
output.

-Jarno

-- 
Jarno Huuskonen

Re: [RFC PATCH] BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2

[Emmanuel Hocdet]

Hi,

This thread reminds me that with BoringSSL empty (and abort) handshake is not 
set.
After tests BoringSSL seems to have simpler case.
I sent a patch to fix that.

For OpenSSL <= 1.0.2, revert is the thing to do.
For LibreSSL, include it with BoringSSL case could be ok (with my patch).
With time (no HB and better error report in libSSL), it seems code could simply 
look like:
  if (!errno)
  conn->err_code = CO_ER_SSL_EMPTY;
  else
  conn->err_code = CO_ER_SSL_ABORT;

++
Manu

> Le 4 juil. 2019 à 12:14, Lukas Tribus  a écrit :
> 
> Hello Ilya,
> 
> 
> On Mon, 1 Jul 2019 at 23:08, Илья Шипицин  > wrote:
>> 
>> 
>> 
>> вт, 2 июл. 2019 г. в 01:34, Willy Tarreau :
>>> 
>>> On Mon, Jul 01, 2019 at 10:32:29PM +0200, Lukas Tribus wrote:
 Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including")
 changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL,
 from accessing packet_length directly (not available in LibreSSL) to
 calling SSL_state() instead.
>>> (...)
>>> 
>>> Thanks a lot Lukas. Just out of curiosity, do you have any idea of a
>>> concrete user-visible issue this bug can cause ? It would help bisecting
>>> issues later. I don't know in what case an empty handshake may happen.
>> 
>> 
>> nmap scan ?
> 
> Ilya, just to avoid misunderstandings, I would like to have your
> feedback on this patch so we can decide whether to commit it or work
> on counter-proposals.
> 
> 
> Thanks,
> Lukas

Re: Error with AddressSanitizer

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

did you also use USE_OBSOLETE_LINKER=1 ?
asan is supposed to be used together with obsolete linking

чт, 4 июл. 2019 г. в 19:14, :

> Hi
>
> I got this error when trying to debug a problem in haproxy
>
> compile haproxy using clang with -fsanitize=address and start haproxy:
>
>
> =
> ==27669==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x019795c8 at pc 0xb28240 bp 0x7ffd7682c2d0 sp 0x7ffd7682c2c8
> READ of size 8 at 0x019795c8 thread T0
> #0 0xb2823f in main src/haproxy.c:2710
> #1 0x7fb34cee8444 in __libc_start_main
> /usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274
> #2 0x49299c in _start (haproxy+0x49299c)
>
> 0x019795c8 is located 56 bytes to the left of global variable
> '__initcb_509' from 'src/task.c' (0x1979600) of size 8
> 0x019795c8 is located 0 bytes to the right of global variable
> '__initcb_1860' from 'src/log.c' (0x19795c0) of size 8
> SUMMARY: AddressSanitizer: global-buffer-overflow src/haproxy.c:2710 main
> Shadow bytes around the buggy address:
>   0x80327260: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
>   0x80327270: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
>   0x80327280: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
>   0x80327290: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
>   0x803272a0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
> =>0x803272b0: 00 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9 f9 f9 f9 f9
>   0x803272c0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
>   0x803272d0: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x803272e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x803272f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80327300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone: fa
>   Heap right redzone:fb
>   Freed heap region: fd
>   Stack left redzone:f1
>   Stack mid redzone: f2
>   Stack right redzone:   f3
>   Stack partial redzone: f4
>   Stack after return:f5
>   Stack use after scope: f8
>   Global redzone:f9
>   Global init order: f6
>   Poisoned by user:  f7
>   ASan internal: fe
> ==27669==ABORTING
>
>
>

[PATCH] BUG/MINOR: ssl: empty handshake detection for BoringSSL

[Emmanuel Hocdet]

Hi,

This patch fix BoringSSL case.

++
Manu



0001-BUG-MINOR-ssl-empty-handshake-detection-for-BoringSS.patch
Description: Binary data

RE: issue with small object caching

[Senthil Naidu]

Hi,

I there any fix that can be applied for small object caching to work with 
Firefox and chrome too, With Internet Explorer I am able to hit the cache 
properly.

As mentioned in my earlier  , I can see that firefox is sending  header 
Cache-Control: no-cache and  Pragma: no-cache , While IE is not sending this 
headers

Regards
Senthil




Senthil Naidu
General Manager - IT Engineering
IT Engineering

Netmagic (An NTT Communications Company)

Direct: +91 22 40090100 | Cell: 7738784713
Email: sent...@netmagicsolutions.com

Linkedin | Twitter | Youtube | Blog | News | Whitepapers | Case Studies

-Original Message-
From: Senthil Naidu
Sent: 03 July 2019 17:00
To: 'Tim Düsterhus'; Christopher Faulet; haproxy@formilux.org
Subject: RE: issue with small object caching

Hi Tim,

Thanks , I am seeing the same headers on chrome too any idea how to disable 
this.

Regards
Senthil

-Original Message-
From: Tim Düsterhus [mailto:t...@bastelstu.be]
Sent: 03 July 2019 16:57
To: Senthil Naidu; Christopher Faulet; haproxy@formilux.org
Subject: Re: issue with small object caching

Senthil,

Am 03.07.19 um 13:20 schrieb Senthil Naidu:
> From Firefox
> *snip*
> Cache-Control: no-cache

This is the issue. Firefox requests that an intermediate proxy does not cache 
(or rather: that it re-validates its cached copy).

Best regards
Tim Düsterhus

Error with AddressSanitizer

[flamesea12]

Hi

I got this error when trying to debug a problem in haproxy

compile haproxy using clang with -fsanitize=address and start haproxy:


=
==27669==ERROR: AddressSanitizer: global-buffer-overflow on address 
0x019795c8 at pc 0xb28240 bp 0x7ffd7682c2d0 sp 0x7ffd7682c2c8
READ of size 8 at 0x019795c8 thread T0
    #0 0xb2823f in main src/haproxy.c:2710
    #1 0x7fb34cee8444 in __libc_start_main 
/usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274
    #2 0x49299c in _start (haproxy+0x49299c)

0x019795c8 is located 56 bytes to the left of global variable 
'__initcb_509' from 'src/task.c' (0x1979600) of size 8
0x019795c8 is located 0 bytes to the right of global variable 
'__initcb_1860' from 'src/log.c' (0x19795c0) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow src/haproxy.c:2710 main
Shadow bytes around the buggy address:
  0x80327260: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x80327270: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x80327280: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x80327290: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x803272a0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
=>0x803272b0: 00 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9 f9 f9 f9 f9
  0x803272c0: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x803272d0: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x803272e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x803272f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80327300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==27669==ABORTING

Get http connection client/server ip/port

[Peter Hudec]

Hi,

I have maybe found some bug in haproxy, submitted as 
https://github.com/haproxy/haproxy/issues/154.

The variables dst, dst_port are identical with the src, src_port.

Is there any other way how to get these /in this case dst/ values ??

What do I need is ..

http-request set-header X-Server-IP %[dst]
http-request set-header X-Server-Port %[dst_port]
http-request set-header X-Client-IP %[src]
http-request set-header X-Client-Port %[src_port]

result is ;(

  'HTTP_X_CLIENT_PORT' => '22696',
  'HTTP_X_CLIENT_IP' => '217.73.20.190',
  'HTTP_X_SERVER_PORT' => '22696',
  'HTTP_X_SERVER_IP' => '217.73.20.190’,

regards
Peter

Re: tfo on default-server settings

[Olivier Houchard]

Hi Fred,

On Thu, Jul 04, 2019 at 02:37:55PM +0200, Frederic Lecaille wrote:
> On 7/4/19 1:36 PM, Olivier Houchard wrote:
> > Hi William,
> > 
> > On Wed, Jul 03, 2019 at 04:52:14PM +, William Dauchy wrote:
> > > Hello,
> > > 
> > > On haproxy v2.0.x, while using tfo option in default-server:
> > >   default-server inter 5s fastinter 1s fall 3 slowstart 20s observe 
> > > layer7 error-limit 5 on-error fail-check pool-purge-delay 10s tfo
> > > we are getting:
> > >   'default-server inter' : 'tfo' option is not accepted in default-server 
> > > sections.
> > > 
> > > from https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#5.2-tfo
> > > 
> > > Is tfo excluded from default-server options?
> > 
> > There's indeed no reason to disallow tfo on default-server, it was an
> > oversight, it is fixed in master with commit
> > 8d82db70a5f32427fb592a947d2a612bcb01d95e, and should be backported in 2.0
> > before the next release.
> > 
> > Regards,
> > 
> > Olivier
> > 
> 
> This makes me think we should perhaps add "no-tfo" option as this is already
> done for several other "server" options.
> 
> The attached patch should do the trick.
> 
> Fred.


Ooops, very good point.
I just pushed your patch, thanks a lot !

Olivier

Re: tfo on default-server settings

[Frederic Lecaille]

On 7/4/19 1:36 PM, Olivier Houchard wrote:

Hi William,

On Wed, Jul 03, 2019 at 04:52:14PM +, William Dauchy wrote:

Hello,

On haproxy v2.0.x, while using tfo option in default-server:
  default-server inter 5s fastinter 1s fall 3 slowstart 20s observe layer7 
error-limit 5 on-error fail-check pool-purge-delay 10s tfo
we are getting:
  'default-server inter' : 'tfo' option is not accepted in default-server 
sections.

from https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#5.2-tfo

Is tfo excluded from default-server options?


There's indeed no reason to disallow tfo on default-server, it was an
oversight, it is fixed in master with commit
8d82db70a5f32427fb592a947d2a612bcb01d95e, and should be backported in 2.0
before the next release.

Regards,

Olivier



This makes me think we should perhaps add "no-tfo" option as this is 
already done for several other "server" options.


The attached patch should do the trick.

Fred.
>From 4cdb7e6359fa42c68c38161d424d9402028b8497 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Thu, 4 Jul 2019 14:19:06 +0200
Subject: [PATCH] MINOR: server: Add "no-tfo" option.

Simple patch to add "no-tfo" option to "default-server" and "server" lines
to disable any usage of TCP fast open.

Must be backported to 2.0.
---
 doc/configuration.txt | 9 -
 src/server.c  | 9 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index de092dc28..2dbbb46c8 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -12127,6 +12127,13 @@ no-verifyhost
   It may also be used as "default-server" setting to reset any previous
   "default-server" "verifyhost" setting.
 
+no-tfo
+  This option may be used as "server" setting to reset any "tfo"
+  setting which would have been inherited from "default-server" directive as
+  default value.
+  It may also be used as "default-server" setting to reset any previous
+  "default-server" "tfo" setting.
+
 non-stick
   Never add connections allocated to this sever to a stick-table.
   This may be used in conjunction with backup to ensure that
@@ -12482,7 +12489,7 @@ tfo
   See the "tfo" bind option for more information about TCP fast open.
   Please note that when using tfo, you should also use the "conn-failure",
   "empty-response" and "response-timeout" keywords for "retry-on", or haproxy
-  won't be able to retry the connection on failure.
+  won't be able to retry the connection on failure. See also "no-tfo".
 
 track [/]
   This option enables ability to set the current state of the server by tracking
diff --git a/src/server.c b/src/server.c
index 15c8ffe6a..02fa2a46c 100644
--- a/src/server.c
+++ b/src/server.c
@@ -583,6 +583,14 @@ static int srv_parse_no_send_proxy_v2(char **args, int *cur_arg,
 	return srv_disable_pp_flags(newsrv, SRV_PP_V2);
 }
 
+/* Parse the "no-tfo" server keyword */
+static int srv_parse_no_tfo(char **args, int *cur_arg,
+struct proxy *curproxy, struct server *newsrv, char **err)
+{
+	newsrv->flags &= ~SRV_F_FASTOPEN;
+	return 0;
+}
+
 /* Parse the "non-stick" server keyword */
 static int srv_parse_non_stick(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
@@ -1354,6 +1362,7 @@ static struct srv_kw_list srv_kws = { "ALL", { }, {
 	{ "no-check-send-proxy", srv_parse_no_check_send_proxy, 0,  1 }, /* disable PROXY protol for health checks */
 	{ "no-send-proxy",   srv_parse_no_send_proxy,   0,  1 }, /* Disable use of PROXY V1 protocol */
 	{ "no-send-proxy-v2",srv_parse_no_send_proxy_v2,0,  1 }, /* Disable use of PROXY V2 protocol */
+	{ "no-tfo",  srv_parse_no_tfo,  0,  1 }, /* Disable use of TCP Fast Open */
 	{ "non-stick",   srv_parse_non_stick,   0,  1 }, /* Disable stick-table persistence */
 	{ "observe", srv_parse_observe, 1,  1 }, /* Enables health adjusting based on observing communication with the server */
 	{ "pool-max-conn",   srv_parse_pool_max_conn,   1,  1 }, /* Set the max number of orphan idle connections, 0 means unlimited */
-- 
2.11.0

Re: tfo on default-server settings

[William Dauchy]

On Thu, Jul 04, 2019 at 01:36:48PM +0200, Olivier Houchard wrote:
> There's indeed no reason to disallow tfo on default-server, it was an
> oversight, it is fixed in master with commit
> 8d82db70a5f32427fb592a947d2a612bcb01d95e, and should be backported in 2.0
> before the next release.

Thanks!
-- 
William

Re: tfo on default-server settings

[Olivier Houchard]

Hi William,

On Wed, Jul 03, 2019 at 04:52:14PM +, William Dauchy wrote:
> Hello,
> 
> On haproxy v2.0.x, while using tfo option in default-server:
>  default-server inter 5s fastinter 1s fall 3 slowstart 20s observe layer7 
> error-limit 5 on-error fail-check pool-purge-delay 10s tfo
> we are getting:
>  'default-server inter' : 'tfo' option is not accepted in default-server 
> sections.
> 
> from https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#5.2-tfo
> 
> Is tfo excluded from default-server options?

There's indeed no reason to disallow tfo on default-server, it was an
oversight, it is fixed in master with commit
8d82db70a5f32427fb592a947d2a612bcb01d95e, and should be backported in 2.0
before the next release.

Regards,

Olivier

Re: [RFC PATCH] BUG/MINOR: ssl: revert empty handshake detection in OpenSSL <= 1.0.2

[Lukas Tribus]

Hello Ilya,


On Mon, 1 Jul 2019 at 23:08, Илья Шипицин  wrote:
>
>
>
> вт, 2 июл. 2019 г. в 01:34, Willy Tarreau :
>>
>> On Mon, Jul 01, 2019 at 10:32:29PM +0200, Lukas Tribus wrote:
>> > Commit 54832b97 ("BUILD: enable several LibreSSL hacks, including")
>> > changed empty handshake detection in OpenSSL <= 1.0.2 and LibreSSL,
>> > from accessing packet_length directly (not available in LibreSSL) to
>> > calling SSL_state() instead.
>> (...)
>>
>> Thanks a lot Lukas. Just out of curiosity, do you have any idea of a
>> concrete user-visible issue this bug can cause ? It would help bisecting
>> issues later. I don't know in what case an empty handshake may happen.
>
>
> nmap scan ?

Ilya, just to avoid misunderstandings, I would like to have your
feedback on this patch so we can decide whether to commit it or work
on counter-proposals.


Thanks,
Lukas