Willy -
Thanks for the information about the roadmap.
Regarding your comment:
> I'm having a hard time believing this, I've been using this combination a
> lot during tests to ensure there was no issue, simply because it involves
> multiple processing during connection accept or setup. That does not mean
> there was no regression since, but I'd like to see the exact setup that is
> exhibiting a handshake failure.
Here is the configuration I used for experimenting with proxy protocol with
SSL between two HAProxy servers. This configuration results in a handshake
failure between HAProxy1 and HAProxy2:
#=== HAProxy 1 =====
frontend h1
mode tcp
bind 10.10.10.241:443 name example ssl crt
/etc/haproxy/keys/haproxy1.pem verify required ca-file
/etc/haproxy/keys/rootCA.pem
default_backend b1
backend b1
server haproxy2 10.10.10.242:443 ssl verify required ca-file
/etc/haproxy/keys/rootCA.pem send-proxy
#=== HAProxy 2 =====
frontend h2
mode tcp
bind 10.10.10.242:443 name example1 ssl crt
/etc/haproxy/keys/haproxy2.pem verify required ca-file
/etc/haproxy/keys/rootCA.pem accept-proxy
default_backend b
backend b
server server1 10.10.10.243:10001 send-proxy
After experimenting a little more, I found it does work if I turn off
mutual authentication between the servers (i.e. change bind
172.18.154.242:443 to verify none).
Bob
On Wed, Mar 26, 2014 at 5:50 PM, Willy Tarreau <[email protected]> wrote:
> Hi Bob,
>
> On Tue, Mar 25, 2014 at 01:58:12PM -0400, Bob S wrote:
> > Basic question on send-proxy:
> >
> > If the HAProxy server configuration has both SSL and send-proxy, should
> the
> > proxy protocol header be sent encrypted within the SSL packet? On
> > 1.5-dev22, I see it being sent outside of the encrypted envelope.
>
> Yes, as documented in the protocol spec. PROXY protocol is
> application-layer
> agnostic and must be sent as the very first thing. Think of it as a TCP
> extension.
>
> However, it's planned in the spec to support an alternative mode where we
> would wait for the PROXY protocol line after the incoming SSL session is
> accepted. I know it's not necessarily obvious, but it's the following line
> in the roadmap file :
>
> tcp-request session expect-proxy {L4|L5} if ...
>
> L4 means we have it on top of TCP, L5 means we have it on top of SSL. And
> equivalently we'd have "send-proxy-l5" on the server side *if needed*,
> which is still unsure to me.
>
> > This
> > causes a handshake failure, even when connecting to another HAProxy (that
> > is, one with SSL and accept-proxy configured).
>
> I'm having a hard time believing this, I've been using this combination a
> lot during tests to ensure there was no issue, simply because it involves
> multiple processing during connection accept or setup. That does not mean
> there was no regression since, but I'd like to see the exact setup that is
> exhibiting a handshake failure.
>
> Regards,
> Willy
>
>
