Hi,
I've been playing around with the ECC+RSA certificate on same IP as
described in the haproxy blog at
http://blog.haproxy.com/2015/07/15/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/
However, I get unexpected results when testing and I'm thinking that
my problem is with the sample fetching of req.ssl_ec_ext on incoming
requests being inconsistent or haproxy starts processing the request
before enough of the data has been sent. I don't know how to
troubleshoot any further or how to get it working, if it's at all
expected to work "as advertised".
I've reduced the setup to a simple test case, without any certificates
or anything like that. I'm using the following configuration:
(NOTE: Yes, i'm fully aware that this config is not a valid ssl/tls
config! I'm using it to illustrate the problem in frontend tcp-relay
which happens before any certificates get involved)
--- start of haproxy.cfg ---
global
log /dev/log local0
defaults
log global
timeout client 5s
timeout server 5s
timeout connect 5s
frontend tcp-relay
mode tcp
option tcplog
bind *:443
use_backend yes-be-ecc if { req.ssl_ec_ext 1 }
default_backend no-be-ecc
backend yes-be-ecc
mode http
option httplog
server yes-ecc 127.0.0.1:80
backend no-be-ecc
mode http
option httplog
server no-ecc 127.0.0.1:80
--- end of haproxy.cfg ---
Then to test, I'd repeatedly issue the following openssl command and
watch the logs for which backend haproxy selected.
# openssl s_client -tls1_2 -no_ticket -cipher
ECDHE-ECDSA-AES256-GCM-SHA384 -connect 127.0.0.1:443
output from log:
tcp-relay no-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay no-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay no-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay no-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay no-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
Mostly it doensn't select the ECC backend, but occationally it does,
about 1 out of 10 times on my VM.
The interesting part comes when i use tcpflow to extract the
ClientHello packet using tcpflow, and then just netcat:ing the same
clienthello message to the server port:
# tcpflow -i lo dst port 443 &
# openssl s_client -tls1_2 -no_ticket -cipher
ECDHE-ECDSA-AES256-GCM-SHA384 -connect 127.0.0.1:443
# fg
<press ctrl-c>
run this a bunch of times:
# cat 127.000.000.001.60092-127.000.000.001.00443 | nc 127.0.0.1 443
output from log:
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay no-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
tcp-relay yes-be-ecc/<NOSRV> -1/-1/0 187 PR 0/0/0/0/3 0/0
Then it seem to work most of the time, only 1 of 20 are sent to the
wrong backend.
Just for fun i tried pushing the file at different bitrates to
haproxy, and at ~1500bps, I would start seeing failures.
mostly works;
# pv -q -L 1700 127.000.000.001.60092-127.000.000.001.00443 | nc 127.0.0.1 443
always fails:
# pv -q -L 1400 127.000.000.001.60092-127.000.000.001.00443 | nc 127.0.0.1 443
I'm running on Ubuntu Trusty, latest stable haproxy 1.6.5 from Vincent
Bernats PPA.
Am I right to assume that fetches such as req.ssl_ec_ext which is used
to build conditions should always work?
Have I made catastrophic config-errors in my test-case that I'm
totally missing?
Please advice :-)
Best regards
Björn Zettergren
