Re: HAProxy proxy protocol support

20.11.2020, 23:11, "Paul B. Henson" <[email protected]>:

On 11/20/2020 4:52 AM, Howard Chu wrote:

client and the proxy server. But nobody says the proxy server can't
talk to the backend server using its own TLS session. Unless you can
point out anywhere in the HAproxy spec that explicitly forbids this.

Eeehhhh.... I don't think it explicitly forbids it, but that's just not
how it says the protocol works :).

Hello,

obviously you can be set Haproxy as a reverse proxy. ın this case all TLS communication and SSL termination is provided with background OpenLDAP server. The proxy server will only act as a reverse-proxy.

You can also provide this with Nginx, set TCP mode and configuring Haproxy will only have reverse proxy.

For example:

frontend ldaps

bind *:636

option tcplog

mode tcp

default_backend ldapserver

backend ldapserver

mode tcp

balance roundrobin

option ssl-hello-chk

server ldap1 10.10.10.2:636 check

server ldap2 10.10.10.3:636 check backup

"Another approach consists in prepending each connection with a header
reporting
the characteristics of the other side's connection. This method is
simpler to
implement, does not require any protocol-specific knowledge on either
side, and
completely fits the purpose since what is desired precisely is to know the
other side's connection endpoints. It is easy to perform for the sender
(just
send a short header once the connection is established) and to parse for the
receiver (simply perform one read() on the incoming connection to fill in
addresses after an accept). The protocol used to carry connection
information
across proxies was thus called the PROXY protocol."

The intention is to be "simple", not require any "protocol specific
knowledge" (such as whether or not the connection being proxied uses
TLS), and is implemented as "just send a short header", which doesn't
explicitly forbid doing a bunch of other stuff, but that's not what is
specified.

Another excerpt:

"In both cases, the protocol simply consists in an easily parsable
header placed
by the connection initiator at the beginning of each connection. The
protocol
is intentionally stateless in that it does not expect the sender to wait for
the receiver before sending the header, nor the receiver to send
anything back."

Negotiating its own TLS session would not be stateless…