Re: SSL load-balancing across multiple HAProxy instances
I think this is the issue in the mode http frontend:
req_ssl_hello_type : integer (deprecated)
this will not work with "bind" lines having the "ssl"
Patrick Hemmer schreef op 14-2-2014 22:34:
You haven't told it to use SSL when talking to the servers listening
on :4443. By default haproxy is going to use non-SSL TCP.
Add the `ssl` option to both of your `server` parameters.
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-ssl
-Patrick
*From: *m...@hawknetdesigns.com
*Sent: * 2014-02-14 16:21:02 E
*To: *haproxy@formilux.org
*Subject: *SSL load-balancing across multiple HAProxy instances
Hi all,
I'm working on a load-balanced instance using HAProxy, Varnish, and
back-end web servers.
I've successfully tested the new SSL termination feature using dev
build 1.5-dev22-1a34d57 2014/02/03, and it works well, however, I
want to load-balance the SSL terminal feature across more than 1
HAProxy instance like so:
Main HAProxy instance on 192.168.1.5, secondary on 192.168.1.10
Varnish servers on 192.168.1.20 and 192.168.1.30
Previously, I was terminating SSL on the single active HAProxy
(192.168.1.5), and speaking HTTP to the Varnish back-ends. This
works well.
What I'd like to do is
Request comes in to HAProxy on port 443. Request is then load
balanced to the two HAProxy servers in tcp mode to 192.168.1.5:4443
and 192.168.1.10:4443 - maintaining SSL mode until it terminates at
port 4443.
An example config (just the relevant sections) would be this:
listen ssl_relay
bind 192.168.1.5:443
mode tcp
option socket-stats
#option ssl-hello-chk
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
tcp-request content accept if { req_ssl_hello_type 1 }
default_backend test
frontend incoming
bind 192.168.1.5:80
mode http
log global
option forwardfor
bind 192.168.1.5:4443 no-sslv3 ssl crt /certs/haproxy.pem crt
/certs/ ciphers RC4-SHA:AES128-SHA:AES256-SHA
mode http
log global
option forwardfor
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
backend test
mode tcp
balance roundrobin
# maximum SSL session ID length is 32 bytes.
stick-table type binary len 32 size 30k expire 30m
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
# use tcp content accepts to detects ssl client and server
hello.
tcp-request inspect-delay 5s
tcp-request content accept if clienthello
# no timeout on response inspect delay by default.
tcp-response content accept if serverhello
# SSL session ID (SSLID) may be present on a client or server
hello.
# Its length is coded on 1 byte at offset 43 and its value
starts
# at offset 44.
# Match and learn on request if client hello.
stick on payload_lv(43,1) if clienthello
# Learn on response if server hello.
stick store-response payload_lv(43,1) if serverhello
server test1 192.168.1.5:4443
server test2 192.168.1.10:4443
http works, and I receive requests on port 443, but this is all I get
from the HAProxy log:
:ssl_relay.accept(0006)=0009 from [192.168.1.2:50496]
:test.clireq[0009:]:
:test.clicls[0009:]
:test.closed[0009:]
It appears that HAProxy is not speaking or passing through SSL to the
frontend on port 4443.
curl -i https://192.168.1.5/
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol
So... what am I missing?
Cheers,
-=Mark
Re: SSL load-balancing across multiple HAProxy instances
You haven't told it to use SSL when talking to the servers listening on
:4443. By default haproxy is going to use non-SSL TCP.
Add the `ssl` option to both of your `server` parameters.
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-ssl
-Patrick
*From: *m...@hawknetdesigns.com
*Sent: * 2014-02-14 16:21:02 E
*To: *haproxy@formilux.org
*Subject: *SSL load-balancing across multiple HAProxy instances
> Hi all,
>
> I'm working on a load-balanced instance using HAProxy, Varnish, and
> back-end web servers.
>
> I've successfully tested the new SSL termination feature using dev
> build 1.5-dev22-1a34d57 2014/02/03, and it works well, however, I want
> to load-balance the SSL terminal feature across more than 1 HAProxy
> instance like so:
>
> Main HAProxy instance on 192.168.1.5, secondary on 192.168.1.10
>
> Varnish servers on 192.168.1.20 and 192.168.1.30
>
> Previously, I was terminating SSL on the single active HAProxy
> (192.168.1.5), and speaking HTTP to the Varnish back-ends. This works
> well.
>
> What I'd like to do is
>
> Request comes in to HAProxy on port 443. Request is then load
> balanced to the two HAProxy servers in tcp mode to 192.168.1.5:4443
> and 192.168.1.10:4443 - maintaining SSL mode until it terminates at
> port 4443.
>
> An example config (just the relevant sections) would be this:
>
> listen ssl_relay
> bind 192.168.1.5:443
> mode tcp
> option socket-stats
> #option ssl-hello-chk
> tcp-request inspect-delay 5s
> tcp-request content accept if { req_ssl_hello_type 1 }
> tcp-request content accept if { req_ssl_hello_type 1 }
> default_backend test
>
> frontend incoming
> bind 192.168.1.5:80
> mode http
> log global
> option forwardfor
> bind 192.168.1.5:4443 no-sslv3 ssl crt /certs/haproxy.pem crt
> /certs/ ciphers RC4-SHA:AES128-SHA:AES256-SHA
> mode http
> log global
> option forwardfor
> tcp-request inspect-delay 5s
> tcp-request content accept if { req_ssl_hello_type 1 }
>
>
> backend test
> mode tcp
> balance roundrobin
> # maximum SSL session ID length is 32 bytes.
> stick-table type binary len 32 size 30k expire 30m
>
> acl clienthello req_ssl_hello_type 1
> acl serverhello rep_ssl_hello_type 2
>
> # use tcp content accepts to detects ssl client and server hello.
> tcp-request inspect-delay 5s
> tcp-request content accept if clienthello
>
> # no timeout on response inspect delay by default.
> tcp-response content accept if serverhello
>
> # SSL session ID (SSLID) may be present on a client or server
> hello.
> # Its length is coded on 1 byte at offset 43 and its value starts
> # at offset 44.
>
> # Match and learn on request if client hello.
> stick on payload_lv(43,1) if clienthello
>
> # Learn on response if server hello.
> stick store-response payload_lv(43,1) if serverhello
>
> server test1 192.168.1.5:4443
> server test2 192.168.1.10:4443
>
> http works, and I receive requests on port 443, but this is all I get
> from the HAProxy log:
>
> :ssl_relay.accept(0006)=0009 from [192.168.1.2:50496]
> :test.clireq[0009:]:
> :test.clicls[0009:]
> :test.closed[0009:]
>
> It appears that HAProxy is not speaking or passing through SSL to the
> frontend on port 4443.
>
> curl -i https://192.168.1.5/
> curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
> protocol
>
> So... what am I missing?
>
> Cheers,
> -=Mark
>
>
>
SSL load-balancing across multiple HAProxy instances
Hi all,
I'm working on a load-balanced instance using HAProxy, Varnish, and
back-end web servers.
I've successfully tested the new SSL termination feature using dev build
1.5-dev22-1a34d57 2014/02/03, and it works well, however, I want to
load-balance the SSL terminal feature across more than 1 HAProxy
instance like so:
Main HAProxy instance on 192.168.1.5, secondary on 192.168.1.10
Varnish servers on 192.168.1.20 and 192.168.1.30
Previously, I was terminating SSL on the single active HAProxy
(192.168.1.5), and speaking HTTP to the Varnish back-ends. This works
well.
What I'd like to do is
Request comes in to HAProxy on port 443. Request is then load balanced
to the two HAProxy servers in tcp mode to 192.168.1.5:4443 and
192.168.1.10:4443 - maintaining SSL mode until it terminates at port
4443.
An example config (just the relevant sections) would be this:
listen ssl_relay
bind 192.168.1.5:443
mode tcp
option socket-stats
#option ssl-hello-chk
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
tcp-request content accept if { req_ssl_hello_type 1 }
default_backend test
frontend incoming
bind 192.168.1.5:80
mode http
log global
option forwardfor
bind 192.168.1.5:4443 no-sslv3 ssl crt /certs/haproxy.pem crt
/certs/ ciphers RC4-SHA:AES128-SHA:AES256-SHA
mode http
log global
option forwardfor
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
backend test
mode tcp
balance roundrobin
# maximum SSL session ID length is 32 bytes.
stick-table type binary len 32 size 30k expire 30m
acl clienthello req_ssl_hello_type 1
acl serverhello rep_ssl_hello_type 2
# use tcp content accepts to detects ssl client and server
hello.
tcp-request inspect-delay 5s
tcp-request content accept if clienthello
# no timeout on response inspect delay by default.
tcp-response content accept if serverhello
# SSL session ID (SSLID) may be present on a client or server
hello.
# Its length is coded on 1 byte at offset 43 and its value
starts
# at offset 44.
# Match and learn on request if client hello.
stick on payload_lv(43,1) if clienthello
# Learn on response if server hello.
stick store-response payload_lv(43,1) if serverhello
server test1 192.168.1.5:4443
server test2 192.168.1.10:4443
http works, and I receive requests on port 443, but this is all I get
from the HAProxy log:
:ssl_relay.accept(0006)=0009 from [192.168.1.2:50496]
:test.clireq[0009:]:
:test.clicls[0009:]
:test.closed[0009:]
It appears that HAProxy is not speaking or passing through SSL to the
frontend on port 4443.
curl -i https://192.168.1.5/
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol
So... what am I missing?
Cheers,
-=Mark
RE: I have a question, would you please help me to solve!
Hi Lukas, I think it is a spam :) Baptiste Le 14 févr. 2014 16:59, "Lukas Tribus" a écrit : > Hi, > > > > Hello: > > > > My name is Zhang Xiaojie > > > > I would like to ask who is haproxy product? I in the website not found > > about haproxy is who the community information or company! > > > The commercial aspect is covered on haproxy.com (exceliance.fr now > redirects > to it): > http://www.haproxy.com/en > > > Opensource/community related is this website: > http://www.haproxy.org/ > > (was haproxy.1wt.eu). > > > > Regards, > > Lukas
RE: Patch for ALPN compatibility with OpenSSL development
Hi,
> Hi all,
>
> At GitHub we’ve worked on a patch to make HAProxy’s ALPN code compatible
> with the patches for it that have landed in OpenSSL:
Great, thats something that needs fixing, yes.
> This final version is slightly different from what HAProxy currently
> expects, which is based on some custom OpenSSL patches.
>
> Let me know if this is a good approach towards fixing this problem or
> that it should be done differently.
I gave it at try against OpenSSL 1.0.2-dev (git head OpenSSL_1_0_2-stable)
from a Google Chrome Browser, but it doesn't look like it behaves correctly.
draft-ietf-tls-applayerprotoneg-04 [1] is the current draf if I understand
correctly, but HAProxy doesn't behave according to the draft.
For example, in 3.1 The Application Layer Protocol Negotiation Extension:
> Servers that receive a client hello containing the
> "application_layer_protocol_negotiation" extension, MAY return a
> suitable protocol selection response to the client.
HAProxy does not select a suitable protocol based on the client hello.
Instead it always sends the fixed lists of ALPN protocols as specified
with the alpn keyword [2]. It even sends protocols the client never even
specified (chrome doesn't specify http/1.0 in alpn) [3].
> The "extension_data"
> field of the ("application_layer_protocol_negotiation(16)") extension
> SHALL be structured the same as described above for the client
> "extension_data", except that the "ProtocolNameList" MUST contain
> exactly one "ProtocolName".
HAProxy responds with all protocols specified with the alpn keyword, instead
of selecting *one single suitable* protocol from the client hello.
Here [4] is a handshake to a google server behaving correctly, by selecting
the single, most suitable protocol in the server hello.
Also, in section 3.2. Protocol Selection:
> It is expected that a server will have a list of protocols that it
> supports, in preference order, and will only select a protocol if the
> client supports it. In that case, the server SHOULD select the most
> highly preferred protocol it supports which is also advertised by the
> client. In the event that the server supports no protocols that the
> client advertises, then the server SHALL respond with a fatal
> "no_application_protocol" alert.
Of course we don't send this alert either, as we don't do any protocol
comparison and selection anywhere.
>From the openssl source file ssl/ssl_lib.c:
> /* SSL_CTX_set_alpn_select_cb sets a callback function on |ctx| that is called
> * during ClientHello processing in order to select an ALPN protocol from the
> * client's list of offered protocols. */
> void SSL_CTX_set_alpn_select_cb(SSL_CTX* ctx,
SSL_CTX_set_alpn_select_cb() is supposed to select the most suitable single
protocol from the client hello.
Looks like we need some additional logic to implement this correctly.
btw: is there any way to easily test this? I don't have a spdy backend
and I didn't find anything relevant in chrome://net-internals/ for
alpn-upgraded http/1.1 connections.
Regards,
Lukas
[1] http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-04
[2] http://cloudshark.org/captures/3e0a8a623142
[3] http://cloudshark.org/captures/293c4d2698d6
[4] http://cloudshark.org/captures/2382b1591cef
RE: I have a question, would you please help me to solve!
Hi, > Hello: > > My name is Zhang Xiaojie > > I would like to ask who is haproxy product? I in the website not found > about haproxy is who the community information or company! The commercial aspect is covered on haproxy.com (exceliance.fr now redirects to it): http://www.haproxy.com/en Opensource/community related is this website: http://www.haproxy.org/ (was haproxy.1wt.eu). Regards, Lukas
[OT] Mozilla is looking for a Cloud Security Engineer
Pardon the off-topic posting, but I figured the members of this list would be interested in looking at this. https://hire.jobvite.com/CompanyJobs/Careers.aspx?nl=1&k=Job&j=ocprYfwK Basic Qualifications * Demonstrated experience rationalizing, implementing, operating and maintaining security controls in cloud and hybrid cloud environments * 3-5 years of experience with security engineering: secure development, cryptography, network security, security operations, systems security, policy, and incident response * Experience with Amazon Web Services (AWS) security. Special focus on building highly resilient, multi regions infrastructures. * Strong understanding of AWS services catalog and architecture. * Experience with Python and developing API clients -- Julien Vehent http://jve.linuxwall.info
I have a question, would you please help me to solve!
Hello: My name is Zhang Xiaojie I would like to ask who is haproxy product? I in the website not found about haproxy is who the community information or company! Thank 张小杰
