I would like to chime in here and confirm that I am seeing very
similar behavior with HAProxy on OpenBSD 6.7,
I was preparing to create my own post on this issue until I saw your thread.
I too believe this is a bug.
I also get the same "Empty reply" response you get via Curl:
> GET / HTTP/1.1
> Host: haproxy.example.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* TLSv1.2 (IN), TLS alert, Client hello (1):
* Empty reply from server
curl: (52) Empty reply from server
For years I have run several OpenBSD Machines with CARP Interfaces and
the HAProxy Load Balancer frontending various services.
I have always used the HAProxy version that is installed via pkg_add,
and for years this has worked out beautifully.
I have upgraded about 8 of the systems from 6.6 to 6.7 and *all* have
exhibited similar behavior when using a TLS backend.
If I switch to a non-TLS backend, it works perfectly, but this of
course breaks the end-to-end encryption that my organization requires.
I have done one further and have taken packet captures to analyze the
traffic pattern in order to try to decipher what is actually
happening,
Below is a summary of the TCP Flow:
OpenBSD 6.6 - haproxy-1.9.15:
-----------------------------------------------------
OpenBSD -> Backend:443 - SYN
Backend:443 -> OpenBSD - SYN/ACK
OpenBSD -> Backend:443 - ACK
OpenBSD -> Backend:443 - TLSv1.2 Client Hello
Backend:443 -> OpenBSD - ACK
Backend:443 -> OpenBSD - ACK
OpenBSD -> Backend:443 - TLSv1.2 Server Hello
OpenBSD -> Backend:443 - ACK
OpenBSD -> Backend:443 - TLSv1.2 Client Key Exhange
<-the rest of the successful session->
OpenBSD 6.7 - haproxy-2.0.14:
-----------------------------------------------------
OpenBSD -> Backend:443 - SYN
Backend:443 -> OpenBSD - SYN/ACK
OpenBSD -> Backend:443 - ACK
OpenBSD -> Backend:443 - TLSv1.2 Application Data
Backend:443 -> OpenBSD - RST/ACK
Note the missing Client Hello on the 6.7 machine as it jumps to
Application Data straight away.
Configuration files for HAProxy are identical on both systems.
I'm currently spinning up a machine on -CURRENT just to see if there
is any difference,
as there is a newer version of HAProxy in packages under Snapshots.
I was initially going to try to reach out to the package maintainer for HAProxy
but if this is happening in Relayd, then this "feels like" a de-facto bug.
I wonder if NGINX would exhibit the same behavior.
Has anyone else experienced such behavior with Load-Balancing TLS
Backends since upgrading to 6.7?
On Thu, Jun 11, 2020 at 4:27 PM Toyam Cox <aviator45...@gmail.com> wrote:
>
> Hello Misc,
>
> Full config at end of email.
>
> I've discussed the below in #openbsd on freenode, and was told to come
> here. At present, I have a setup where I need multiple unrelated
> servers under a single IP address. I used relayd to do https
> interception, read the Host header, and make decisions.
>
> The very relevant part of my config is this:
>
> forward to <httpback> port 80
> forward with tls to <httpsback> port 443
>
> The order here does not matter (unlike most relayd configs, I know,
> but I've tested in my configuration and it works).
>
> When I have "with tls" on that second line, I see error lines like:
> relay web, session 3 (1 active), 0, [redacted] -> 10.0.0.102:80, TLS
> handshake error: handshake failed: error:14FFF3E7:SSL
> routines:(UNKNOWN)SSL_internal:unknown failure occurred, GET:
> Undefined error: 0
>
> and, unhelpfully, relayd responds with no response. There is no
> return. Or, as curl puts it: curl: (52) Empty reply from server
>
> When I remove "with tls" then I successfully reach the http backend,
> but since the https backend requires ssl, that connection no longer
> works. So it seems that 'with tls" affects all "forward" clauses, not
> just the one to which it's attached.
>
> I believe this to be a bug.
>
> cat >/etc/relayd.conf <<EOF
> table <httpsback> { "10.0.0.101" }
> table <httpback> { "10.0.0.102" }
> # obviously obfuscated some values
>
> interval 5
> timeout 1000
>
> log connection
>
> http protocol web {
> return error
>
> match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
> match header set "X-Forwarded-For" value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
>
> http websockets
> pass request quick header "Host" value "myhost.example.com" path
> "/Client/*" forward to <httpsback>
> pass request quick header "Host" value "otherhost.example.com" forward
> to <httpback>
>
> block
> }
>
> relay web {
> listen on 10.0.0.100 port 443 tls
> protocol web
>
> forward to <httpback> port 80 check http "/webservice.asmx" code 405
> forward with tls to <httpsback> port 443 check https
> "/Client/SupportedBrowsers.html" host "myhost.example.com" code 200
> }
> EOF
>
