Re: haproxy 1.9.2 with boringssl
Am 24.01.2019 um 15:09 schrieb Aleksandar Lazic: > Am 24.01.2019 um 03:49 schrieb Willy Tarreau: >> On Wed, Jan 23, 2019 at 09:37:46PM +0100, Aleksandar Lazic wrote: >>> >>> Am 23.01.2019 um 21:27 schrieb Willy Tarreau: On Wed, Jan 23, 2019 at 09:08:00PM +0100, Aleksandar Lazic wrote: > Should it be possible to have fe with h1 and be server h2(alpn h2), as I > expect this or similar return value when I go thru haproxy? Yes absolutely. That's even what I'm doing on my tests to try to fix the issues reported by Luke. >>> >>> Okay, perfect. >>> >>> Would you like to share your config so that I can see what's wrong with my >>> config, thanks. >> >> Sure, here's a copy-paste, hoping I don't mess with anything :-) >> >> defaults >> mode http >> option http-use-htx >> option httplog >> log stdout format raw daemon >> timeout connect 4s >> timeout client 10s >> timeout server 10s >> >> frontend decrypt >> bind :4445 >> bind :4446 proto h2 >> bind :4443 ssl crt rsa+dh2048.pem npn h2 alpn h2 >> default_backend trace >> >> backend trace >> stats uri /stat >> server s1 127.0.0.1:443 ssl alpn h2 verify none >> #server s2 127.0.0.1:80 >> #server s3 127.0.0.1:80 proto h2 >> >> As you can see you just connect to port 4445. > > Many thanks. > Sorry for the long mail thread but I'm not able to get a proper answer from > the ssl backend. Please ignore this mail. There is a problem within the container as a curl in the container have the same problem as haproxy, so it's related to the container run. > I have made the setup more easier. > > This setup does not return the stats page. > curl => haproxy-19 with openssl => openssl s_server internal stats page > > This setup does return the stats page. > > ### > curl -vk https://207.154.204.236:4443 > * About to connect() to 207.154.204.236 port 4443 (#0) > * Trying 207.154.204.236... > * Connected to 207.154.204.236 (207.154.204.236) port 4443 (#0) > * Initializing NSS with certpath: sql:/etc/pki/nssdb > * skipping SSL peer certificate verification > * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > * Server certificate: > * subject: CN=h2test.livesystem.at > * start date: Jan 24 12:18:25 2019 GMT > * expire date: Apr 24 12:18:25 2019 GMT > * common name: h2test.livesystem.at > * issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US >> GET / HTTP/1.1 >> User-Agent: curl/7.29.0 >> Host: 207.154.204.236:4443 >> Accept: */* >> > * HTTP 1.0, assume close after body > < HTTP/1.0 200 ok > < Content-type: text/html > < > > > > s_server -www -alpn h2 -cert > /root/.caddy/acme/acme-v02.api.letsencrypt.org/sites/h2test.livesystem.at/h2test.livesystem.at.crt > -key > /root/.caddy/acme/acme-v02.api.letsencrypt.org/sites/h2test.livesystem.at/h2test.livesystem.at.key > -accept 4443 -debug -msg > Secure Renegotiation IS supported > Ciphers supported in s_server binary > . > ### > > # openssl version > OpenSSL 1.0.2k-fips 26 Jan 2017 > > # curl -V > curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.34 zlib/1.2.7 > libidn/1.28 libssh2/1.4.3 > Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 > pop3s rtsp scp sftp smtp smtps telnet tftp > Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz > unix-sockets > > > defaults > mode http > option http-use-htx > option httplog > log stdout format raw daemon debug > timeout connect 4s > timeout client 10s > timeout server 10s > > frontend decrypt > bind :4445 > bind :4446 proto h2 > #bind :4443 ssl crt rsa+dh2048.pem npn h2 alpn h2 > default_backend trace > > backend trace > stats uri /stat > > # localhosts ip > server s1 207.154.204.236:4443 ssl alpn h2 verify none > > > > podman run --rm -it \ > -e SERVICE_DEST=mail.google.com \ > -e LOGLEVEL=debug \ > -e NUM_THREADS=8 \ > -e DNS_SRV001=1.1.1.1 \ > -e DNS_SRV002=8.8.8.8 \ > -e STATS_PORT=7411 \ > -e STATS_USER=test \ > -e STATS_PASSWORD=test \ > -e SERVICE_TCP_PORT=8443 \ > -e SERVICE_NAME=google-mail \ > -e SERVICE_DEST_IP=mail.google.com \ > -e SERVICE_DEST_PORT=443 \ > -e CONFIG_FILE=/mnt/haproxy2.cfg \ > -e DEBUG=1 -v /tmp/:/mnt/ \ > -p 4445 --expose 4445 \ > --net host \ > me2digital/haproxy19 > > > ### > openssl s_server -www -alpn h2 \ > -cert > ~/.caddy/acme/acme-v02.api.letsencrypt.org/sites/h2test.livesystem.at/h2test.livesystem.at.crt > \ > -key > ~/.caddy/acme/acme-v02.api.letsencrypt.org/sites/h2test.livesystem.at/h2test.livesystem.at.key > \ > -accept 4443 -debug -msg > ### > > ### > [root@doh-001 ~]# curl -vk http://127.0.0.1:4445 > * About to connect() to 127.0.0.1 port 4445 (#0) > * Trying
Re: haproxy 1.9.2 with boringssl
Am 24.01.2019 um 03:49 schrieb Willy Tarreau: > On Wed, Jan 23, 2019 at 09:37:46PM +0100, Aleksandar Lazic wrote: >> >> Am 23.01.2019 um 21:27 schrieb Willy Tarreau: >>> On Wed, Jan 23, 2019 at 09:08:00PM +0100, Aleksandar Lazic wrote: Should it be possible to have fe with h1 and be server h2(alpn h2), as I expect this or similar return value when I go thru haproxy? >>> >>> Yes absolutely. That's even what I'm doing on my tests to try to fix >>> the issues reported by Luke. >> >> Okay, perfect. >> >> Would you like to share your config so that I can see what's wrong with my >> config, thanks. > > Sure, here's a copy-paste, hoping I don't mess with anything :-) > > defaults > mode http > option http-use-htx > option httplog > log stdout format raw daemon > timeout connect 4s > timeout client 10s > timeout server 10s > > frontend decrypt > bind :4445 > bind :4446 proto h2 > bind :4443 ssl crt rsa+dh2048.pem npn h2 alpn h2 > default_backend trace > > backend trace > stats uri /stat > server s1 127.0.0.1:443 ssl alpn h2 verify none > #server s2 127.0.0.1:80 > #server s3 127.0.0.1:80 proto h2 > > As you can see you just connect to port 4445. Many thanks. Sorry for the long mail thread but I'm not able to get a proper answer from the ssl backend. I have made the setup more easier. This setup does not return the stats page. curl => haproxy-19 with openssl => openssl s_server internal stats page This setup does return the stats page. ### curl -vk https://207.154.204.236:4443 * About to connect() to 207.154.204.236 port 4443 (#0) * Trying 207.154.204.236... * Connected to 207.154.204.236 (207.154.204.236) port 4443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * skipping SSL peer certificate verification * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 * Server certificate: * subject: CN=h2test.livesystem.at * start date: Jan 24 12:18:25 2019 GMT * expire date: Apr 24 12:18:25 2019 GMT * common name: h2test.livesystem.at * issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US > GET / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 207.154.204.236:4443 > Accept: */* > * HTTP 1.0, assume close after body < HTTP/1.0 200 ok < Content-type: text/html < s_server -www -alpn h2 -cert /root/.caddy/acme/acme-v02.api.letsencrypt.org/sites/h2test.livesystem.at/h2test.livesystem.at.crt -key /root/.caddy/acme/acme-v02.api.letsencrypt.org/sites/h2test.livesystem.at/h2test.livesystem.at.key -accept 4443 -debug -msg Secure Renegotiation IS supported Ciphers supported in s_server binary . ### # openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 # curl -V curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.34 zlib/1.2.7 libidn/1.28 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets defaults mode http option http-use-htx option httplog log stdout format raw daemon debug timeout connect 4s timeout client 10s timeout server 10s frontend decrypt bind :4445 bind :4446 proto h2 #bind :4443 ssl crt rsa+dh2048.pem npn h2 alpn h2 default_backend trace backend trace stats uri /stat # localhosts ip server s1 207.154.204.236:4443 ssl alpn h2 verify none podman run --rm -it \ -e SERVICE_DEST=mail.google.com \ -e LOGLEVEL=debug \ -e NUM_THREADS=8 \ -e DNS_SRV001=1.1.1.1 \ -e DNS_SRV002=8.8.8.8 \ -e STATS_PORT=7411 \ -e STATS_USER=test \ -e STATS_PASSWORD=test \ -e SERVICE_TCP_PORT=8443 \ -e SERVICE_NAME=google-mail \ -e SERVICE_DEST_IP=mail.google.com \ -e SERVICE_DEST_PORT=443 \ -e CONFIG_FILE=/mnt/haproxy2.cfg \ -e DEBUG=1 -v /tmp/:/mnt/ \ -p 4445 --expose 4445 \ --net host \ me2digital/haproxy19 ### openssl s_server -www -alpn h2 \ -cert ~/.caddy/acme/acme-v02.api.letsencrypt.org/sites/h2test.livesystem.at/h2test.livesystem.at.crt \ -key ~/.caddy/acme/acme-v02.api.letsencrypt.org/sites/h2test.livesystem.at/h2test.livesystem.at.key \ -accept 4443 -debug -msg ### ### [root@doh-001 ~]# curl -vk http://127.0.0.1:4445 * About to connect() to 127.0.0.1 port 4445 (#0) * Trying 127.0.0.1... * Connected to 127.0.0.1 (127.0.0.1) port 4445 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 127.0.0.1:4445 > Accept: */* > * HTTP 1.0, assume close after body < HTTP/1.0 503 Service Unavailable < cache-control: no-cache < content-type: text/html < 503 Service Unavailable No server is available to handle this request. * Closing connection 0 ### HAProxy output. exec /usr/local/sbin/haproxy -f /mnt/haproxy2.cfg -d Note: setting global.maxconn to 2000.
Re: haproxy 1.9.2 with boringssl
On Wed, Jan 23, 2019 at 09:37:46PM +0100, Aleksandar Lazic wrote: > > Am 23.01.2019 um 21:27 schrieb Willy Tarreau: > > On Wed, Jan 23, 2019 at 09:08:00PM +0100, Aleksandar Lazic wrote: > >> Should it be possible to have fe with h1 and be server h2(alpn h2), as I > >> expect this or similar return value when I go thru haproxy? > > > > Yes absolutely. That's even what I'm doing on my tests to try to fix > > the issues reported by Luke. > > Okay, perfect. > > Would you like to share your config so that I can see what's wrong with my > config, thanks. Sure, here's a copy-paste, hoping I don't mess with anything :-) defaults mode http option http-use-htx option httplog log stdout format raw daemon timeout connect 4s timeout client 10s timeout server 10s frontend decrypt bind :4445 bind :4446 proto h2 bind :4443 ssl crt rsa+dh2048.pem npn h2 alpn h2 default_backend trace backend trace stats uri /stat server s1 127.0.0.1:443 ssl alpn h2 verify none #server s2 127.0.0.1:80 #server s3 127.0.0.1:80 proto h2 As you can see you just connect to port 4445. > >> I haven't seen any log option to get the backend request method, I think > >> this > >> should be a feature request ;-). > > > > What do you mean with "backend request method" precisely ? > > As the log is for frontends It would be nice to be able to get this infos > from below also for the backend to see what was send to the backend server. But what is sent to the backend is what comes from the frontend. And there never is any valid reason for rewriting the method. So the method sent to the backend is *always* what you receive on the fronend. Cheers, Willy
Re: haproxy 1.9.2 with boringssl
Am 23.01.2019 um 21:27 schrieb Willy Tarreau: > On Wed, Jan 23, 2019 at 09:08:00PM +0100, Aleksandar Lazic wrote: >> Should it be possible to have fe with h1 and be server h2(alpn h2), as I >> expect this or similar return value when I go thru haproxy? > > Yes absolutely. That's even what I'm doing on my tests to try to fix > the issues reported by Luke. Okay, perfect. Would you like to share your config so that I can see what's wrong with my config, thanks. >> I haven't seen any log option to get the backend request method, I think this >> should be a feature request ;-). > > What do you mean with "backend request method" precisely ? As the log is for frontends It would be nice to be able to get this infos from below also for the backend to see what was send to the backend server. The problem what I see is that a tcpdump/tshark does not help to see what's transfered on the wire when the backend talks via TLS. https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#8.2.4 ### current variables | H | %HM | HTTP method (ex: POST)| string | | H | %HP | HTTP request URI without query string (path) | string | | H | %HQ | HTTP request URI query string (ex: ?bar=baz) | string | | H | %HU | HTTP request URI (ex: /foo?bar=baz) | string | | H | %HV | HTTP version (ex: HTTP/1.0) | string | Possible new | H | %bM | Backend HTTP method (ex: POST)| string | | H | %bP | Backend HTTP request URI without query string (path) | string | | H | %bQ | Backend HTTP request URI query string (ex: ?bar=baz) | string | | H | %bU | Backend HTTP request URI (ex: /foo?bar=baz) | string | | H | %bV | Backend HTTP version (ex: HTTP/1.0) | string | ### > Willy Aleks
Re: haproxy 1.9.2 with boringssl
On Wed, Jan 23, 2019 at 09:08:00PM +0100, Aleksandar Lazic wrote: > Should it be possible to have fe with h1 and be server h2(alpn h2), as I > expect this or similar return value when I go thru haproxy? Yes absolutely. That's even what I'm doing on my tests to try to fix the issues reported by Luke. > I haven't seen any log option to get the backend request method, I think this > should be a feature request ;-). What do you mean with "backend request method" precisely ? Willy
Re: haproxy 1.9.2 with boringssl
Hi Willy.
Am 23.01.2019 um 19:50 schrieb Willy Tarreau:
> Hi Aleks,
>
> On Wed, Jan 23, 2019 at 06:58:25PM +0100, Aleksandar Lazic wrote:
>> backend be_generic_tcp
>> mode http
>> balance source
>> timeout check 5s
>> option tcp-check
>>
>> server "${SERVICE_NAME}" ${SERVICE_DEST_IP}:${SERVICE_DEST_PORT} check
>> inter 5s proto h2 ssl ssl-min-ver TLSv1.3 verify none
>
> You need to replace "proto h2" with "alpn h2", so that the application
> protocol is announced to the other host, otherwise it will stick to the
> default, very likely "http/1.1", while haproxy talks h2 there. This can
> explain the 502 when the other side rejected your request.
I have changed it but still no lock.
Should it be possible to have fe with h1 and be server h2(alpn h2), as I expect
this or similar return value when I go thru haproxy?
I haven't seen any log option to get the backend request method, I think this
should be a feature request ;-).
curl -vo /dev/null https://mail.google.com:443
* Trying 172.217.21.229...
* Connected to mail.google.com (172.217.21.229) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=mail.google.com,O=Google LLC,L=Mountain
View,ST=California,C=US
* start date: Dec 19 08:16:00 2018 GMT
* expire date: Mar 13 08:16:00 2019 GMT
* common name: mail.google.com
* issuer: CN=Google Internet Authority G3,O=Google Trust Services,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: mail.google.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: /mail/
< Expires: Wed, 23 Jan 2019 20:01:34 GMT
< Date: Wed, 23 Jan 2019 20:01:34 GMT
< Cache-Control: private, max-age=7776000
< Content-Type: text/html; charset=UTF-8
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alt-Svc: clear
< Accept-Ranges: none
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
<
{ [data not shown]
* Connection #0 to host mail.google.com left intact
Config is now this.
###
cat /tmp/haproxy.cfg
# https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#3
global
# nodaemon
log stdout format rfc5424 daemon "${LOGLEVEL}"
stats socket /tmp/sock1 mode 666 level admin
stats timeout 1h
tune.ssl.default-dh-param 2048
ssl-server-verify none
nbthread "${NUM_THREADS}"
defaults
log global
# the format is described at
# https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#4
# copied from
#
https://github.com/haproxytech/haproxy-docker-arm64v8/blob/master/cfg_files/haproxy.cfg
retries 3
timeout http-request10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
default-server resolve-prefer ipv4 inter 5s resolvers mydns
option http-use-htx
option httplog
log-format ">>> %ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS
%tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r %rt %sslv %sslc"
resolvers mydns
nameserver dns1 "${DNS_SRV001}":53
nameserver dns2 "${DNS_SRV002}":53
resolve_retries 3
timeout retry 1s
hold valid 10s
listen stats
bind :"${STATS_PORT}"
mode http
# Health check monitoring uri.
monitor-uri /healthz
# Add your custom health check monitoring failure condition here.
# monitor fail if
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /
stats auth "${STATS_USER}":"${STATS_PASSWORD}"
frontend public_tcp
bind :"${SERVICE_TCP_PORT}" alpn h2,http/1.1
mode http
log global
default_backend be_generic_tcp
backend be_generic_tcp
mode http
balance source
timeout check 5s
option tcp-check
server "${SERVICE_NAME}" ${SERVICE_DEST_IP}:${SERVICE_DEST_PORT} check inter
5s alpn h2 ssl ssl-min-ver TLSv1.3 verify none
###
Log of haproxy
<29>1 2019-01-23T20:00:30+00:00 doh-001 haproxy 1 - - Proxy stats started.
<29>1 2019-01-23T20:00:30+00:00 doh-001 haproxy 1 - - Proxy public_tcp started.
<29>1 2019-01-23T20:00:30+00:00 doh-001 haproxy 1 - - Proxy be_generic_tcp
started.
[WARNING] 022/200030 (1) : be_generic_tcp/google-mail changed its IP from
172.217.21.229 to 172.217.18.165 by mydns/dns1.
<29>1 2019-01-23T20:00:30+00:00 doh-001 haproxy 1 - -
be_generic_tcp/google-mail changed its IP from 172.217.21.229 to 172.217.18.165
by mydns/dns1.
:public_tcp.accept(0006)=000c from [127.0.0.1:54308] ALPN=
:public_tcp.clireq[000c:]: GET / HTTP/1.1
:public_tcp.clihdr[000c:]: user-agent: curl/7.29.0
:public_tcp.clihdr[000c:]: host: 127.0.0.1:8443
:public_tcp.clihdr[000c:]: accept: */*
:be_generic_tcp.srvcls[000c:0021]
Re: haproxy 1.9.2 with boringssl
Hi Aleks,
On Wed, Jan 23, 2019 at 06:58:25PM +0100, Aleksandar Lazic wrote:
> backend be_generic_tcp
> mode http
> balance source
> timeout check 5s
> option tcp-check
>
> server "${SERVICE_NAME}" ${SERVICE_DEST_IP}:${SERVICE_DEST_PORT} check
> inter 5s proto h2 ssl ssl-min-ver TLSv1.3 verify none
You need to replace "proto h2" with "alpn h2", so that the application
protocol is announced to the other host, otherwise it will stick to the
default, very likely "http/1.1", while haproxy talks h2 there. This can
explain the 502 when the other side rejected your request.
Willy
Re: haproxy 1.9.2 with boringssl
Hi.
After some tricky stuff with centos I switched to debian as base image and was
now able to build haproxy with boringssl.
/usr/local/sbin/haproxy -vv
HA-Proxy version 1.9.2 2019/01/16 - https://haproxy.org/
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
-Wno-missing-field-initializers -Wtype-limits -Wshift-negative-value
-Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
OPTIONS = USE_LINUX_SPLICE=1 USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1
USE_THREAD=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE2=1 USE_PCRE2_JIT=1 USE_TFO=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : BoringSSL
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with PCRE2 version : 10.22 2016-07-29
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
h2 : mode=HTXside=FE|BE
h2 : mode=HTTP side=FE
: mode=HTXside=FE|BE
: mode=TCP|HTTP side=FE|BE
Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace
Now I want to try to make the request to mail.google.com with this config and
runtime.
###
cat /tmp/haproxy.cfg
# https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#3
global
# nodaemon
log stdout format rfc5424 daemon "${LOGLEVEL}"
stats socket /tmp/sock1 mode 666 level admin
stats timeout 1h
tune.ssl.default-dh-param 2048
ssl-server-verify none
nbthread "${NUM_THREADS}"
defaults
log global
# the format is described at
# https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#4
# copied from
#
https://github.com/haproxytech/haproxy-docker-arm64v8/blob/master/cfg_files/haproxy.cfg
retries 3
timeout http-request10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
default-server resolve-prefer ipv4 inter 5s resolvers mydns
option http-use-htx
resolvers mydns
nameserver dns1 "${DNS_SRV001}":53
nameserver dns2 "${DNS_SRV002}":53
resolve_retries 3
timeout retry 1s
hold valid 10s
listen stats
bind :"${STATS_PORT}"
mode http
# Health check monitoring uri.
monitor-uri /healthz
# Add your custom health check monitoring failure condition here.
# monitor fail if
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /
stats auth "${STATS_USER}":"${STATS_PASSWORD}"
frontend public_tcp
bind :"${SERVICE_TCP_PORT}"
mode http
option httplog
log global
default_backend be_generic_tcp
backend be_generic_tcp
mode http
balance source
timeout check 5s
option tcp-check
server "${SERVICE_NAME}" ${SERVICE_DEST_IP}:${SERVICE_DEST_PORT} check inter
5s proto h2 ssl ssl-min-ver TLSv1.3 verify none
###
Test with curl
###
curl -v http://127.0.0.1:8443
* About to connect() to 127.0.0.1 port 8443 (#0)
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 127.0.0.1:8443
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 502 Bad Gateway
< cache-control: no-cache
< content-type: text/html
<
502 Bad Gateway
The server returned an invalid or incomplete response.
* Closing connection 0
###
podmain.io instead of docker
podman run --rm -it -e LOGLEVEL=debug -e NUM_THREADS=8 -e DNS_SRV001=1.1.1.1 -e
DNS_SRV002=8.8.8.8 \
-e STATS_PORT=7411 -e STATS_USER=test -e STATS_PASSWORD=test -e
SERVICE_TCP_PORT=8443 \
-e SERVICE_NAME=google-mail -e SERVICE_DEST_IP=mail.google.com -e
SERVICE_DEST_PORT=443 \
-e CONFIG_FILE=/mnt/haproxy.cfg -v /tmp/:/mnt/ -p 8443 --expose 8443
--net host \
me2digital/haproxy-19-boringssl
using CONFIG_FILE :/mnt/haproxy.cfg
<29>1 2019-01-23T17:50:45+00:00 doh-001 haproxy 1 - - Proxy stats started.
<29>1
Re: haproxy 1.9.2 with boringssl
Hi Aleksandar, Just FYI. Op 22-1-2019 om 22:08 schreef Aleksandar Lazic: But this could be a know bug and is fixed in the current git - ## Starting vtest ## Testing with haproxy version: 1.9.2 #top TEST ./reg-tests/mailers/k_healthcheckmail.vtc FAILED (7.808) exit=2 1 tests failed, 0 tests skipped, 32 tests passed ## Gathering results ## ## Test case: ./reg-tests/mailers/k_healthcheckmail.vtc ## ## test results in: "/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1" c27.0 EXPECT resp.http.mailsreceived (11) == "16" failed This was indeed identified as a bug, and is fixed in current master. The impact of this was rather low though, and this specific issue of a few 'missing' mails under certain configuration circumstances existed for years before it was spotted with the regtest. https://www.mail-archive.com/haproxy@formilux.org/msg32190.html http://git.haproxy.org/?p=haproxy.git;a=commit;h=774c486cece942570b6a9d16afe236a16ee12079 Regards, PiBa-NL (Pieter)
Re: haproxy 1.9.2 with boringssl
Am 22.01.2019 um 21:45 schrieb Adam Langley: > On Tue, Jan 22, 2019 at 12:13 PM Aleksandar Lazic wrote: >> Sorry for my dump question, I just want to be save not to break something. >> >> It would be nice to have the option '-key-update' in client.cc and server.cc >> where can I put this feature request for boringssl? >> >> That would be make the test easy with this command. >> >> `./tool/bssl s_client -key-update -connect $test-haproxy-instance ` > > bssl is just for human experimentation, it shouldn't be used in > something like a test because we break the interface from > time-to-time. (Also note that BoringSSL in general "is not intended > for general use, as OpenSSL is. We don't recommend that third parties > depend upon it." https://boringssl.googlesource.com/boringssl) Yes I have read it and was surprised, but it is how it is. > You may well be better off using OpenSSL for a test like that, or > perhaps writing a C/C++ program (which will probably work for either > OpenSSL or BoringSSL). Well thanks. Currently I have no time wo look into this topic. > Cheers > > AGL Regards Aleks
Re: haproxy 1.9.2 with boringssl
Tim.
Am 22.01.2019 um 20:57 schrieb Tim Düsterhus:
> Aleks,
>
> Am 22.01.19 um 20:50 schrieb Aleksandar Lazic:
>> This means that the function in haproxy works but the check should be
>> adopted to
>> match both cases, right?
>
> At least one should investigate what exactly is happening here (the
> differences between the libc is a guess) and possibly file a bug for
> either glibc or musl. I believe what musl is doing here is correct and
> thus glibc must be incorrect.
>
> Consider filing a tracking bug in haproxy's issue tracker to verify
> where / who exactly is doing something wrong.
Done.
https://github.com/haproxy/haproxy/issues/23
>> Do you think that in general the alpine/musl is a good idea or should I stay
>> on
>> centos as for my other images?
>
> FWIW: There already is an Alpine image for haproxy in Docker Official
> Images:
> https://github.com/docker-library/haproxy/blob/master/1.9/alpine/Dockerfile
Yep, I know, this uses openssl I was curious how difficult is is to run haproxy
with boringssl.
Never the less this Dockerfile have "only" 2 failed tests.
## Starting vtest ##
Testing with haproxy version: 1.9.2
#top TEST ./reg-tests/http-rules/h2.vtc FAILED (0.904) exit=2
#top TEST ./reg-tests/mailers/k_healthcheckmail.vtc FAILED (7.804) exit=2
2 tests failed, 0 tests skipped, 31 tests passed
## Gathering results ##
## Test case: ./reg-tests/http-rules/h2.vtc ##
## test results in:
"/tmp/haregtests-2019-01-22_20-26-25.BmFdCB/vtc.1383.3d3a039a"
s10.0 EXPECT req.http.test3maskff (2001:db8:c001:c01a:::10:0) ==
"2001:db8:c001:c01a:0::10:0" failed
## Test case: ./reg-tests/mailers/k_healthcheckmail.vtc ##
## test results in:
"/tmp/haregtests-2019-01-22_20-26-25.BmFdCB/vtc.1383.06fe4e21"
c27.0 EXPECT resp.http.mailsreceived (11) == "16" failed
make: *** [Makefile:1102: reg-tests] Error 1
This looks like your assumption with musl<>glibc ipv6 handling is different.
> Personally I'm a Debian guy, for containers I prefer Debian based and
> CentOS / RHEL I don't use at all.
Interesting is that even the debian based Image have failed tests
https://github.com/docker-library/haproxy/tree/master/1.9
But this could be a know bug and is fixed in the current git
-
## Starting vtest ##
Testing with haproxy version: 1.9.2
#top TEST ./reg-tests/mailers/k_healthcheckmail.vtc FAILED (7.808) exit=2
1 tests failed, 0 tests skipped, 32 tests passed
## Gathering results ##
## Test case: ./reg-tests/mailers/k_healthcheckmail.vtc ##
## test results in:
"/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1"
c27.0 EXPECT resp.http.mailsreceived (11) == "16" failed
Makefile:1102: recipe for target 'reg-tests' failed
make: *** [reg-tests] Error 1
+ egrep -r ^ /tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/failedtests.log
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/failedtests.log:## Test case:
./reg-tests/mailers/k_healthcheckmail.vtc ##
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/failedtests.log:## test results in:
"/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1"
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/failedtests.log: c27.0
EXPECT resp.http.mailsreceived (11) == "16" failed
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/INFO:Test case:
./reg-tests/mailers/k_healthcheckmail.vtc
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:global
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:stats
socket
"/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/stats.sock"
level admin mode 600
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:stats
socket "fd@${cli}" level admin
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:global
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:
lua-load /usr/src/haproxy/./reg-tests/mailers/k_healthcheckmail.lua
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:defaults
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:
frontend femail
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:
mode tcp
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:
bind "fd@${femail}"
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:
tcp-request content use-service lua.mailservice
/tmp/haregtests-2019-01-22_20-56-31.QMI0Ue/vtc.5740.39907fe1/h1/cfg:
Re: haproxy 1.9.2 with boringssl
On Tue, Jan 22, 2019 at 12:13 PM Aleksandar Lazic wrote: > Sorry for my dump question, I just want to be save not to break something. > > It would be nice to have the option '-key-update' in client.cc and server.cc > where can I put this feature request for boringssl? > > That would be make the test easy with this command. > > `./tool/bssl s_client -key-update -connect $test-haproxy-instance ` bssl is just for human experimentation, it shouldn't be used in something like a test because we break the interface from time-to-time. (Also note that BoringSSL in general "is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it." https://boringssl.googlesource.com/boringssl) You may well be better off using OpenSSL for a test like that, or perhaps writing a C/C++ program (which will probably work for either OpenSSL or BoringSSL). Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
Re: haproxy 1.9.2 with boringssl
Am 22.01.2019 um 20:54 schrieb Adam Langley:
> On Tue, Jan 22, 2019 at 11:45 AM Aleksandar Lazic wrote:
>> Can it be reused to test a specific server like?
>>
>> ssl/test/runner/runner -test "KeyUpdate-ToServer" 127.0.0.1:8443
>
> Not easily: it drives the implementation under test by forking a
> process and has quite a complex interface via command-line arguments.
> (I.e.
> https://boringssl.googlesource.com/boringssl/+/eadef4730e66f914d7b9cbb2f38ecf7989f992ed/ssl/test/test_config.h)
>
>> or should be a small c/go program be used for that test?
>
> You could easily tweak transport_common.cc to call SSL_key_update
> before each SSL_write or so.
Great.
To be on the save site, I would like to add the following lines
###
if (!SSL_key_update(ssl, SSL_KEY_UPDATE_NOT_REQUESTED)) {
fprintf(stderr, "SSL_key_update failed.\n");
return false;
}
###
before this line.
https://boringssl.googlesource.com/boringssl/+/master/tool/transport_common.cc#706
Sorry for my dump question, I just want to be save not to break something.
It would be nice to have the option '-key-update' in client.cc and server.cc
where can I put this feature request for boringssl?
That would be make the test easy with this command.
`./tool/bssl s_client -key-update -connect $test-haproxy-instance `
> Cheers
>
> AGL
Regards
Aleks
Re: haproxy 1.9.2 with boringssl
Aleks, Am 22.01.19 um 20:50 schrieb Aleksandar Lazic: > This means that the function in haproxy works but the check should be adopted > to > match both cases, right? At least one should investigate what exactly is happening here (the differences between the libc is a guess) and possibly file a bug for either glibc or musl. I believe what musl is doing here is correct and thus glibc must be incorrect. Consider filing a tracking bug in haproxy's issue tracker to verify where / who exactly is doing something wrong. > Do you think that in general the alpine/musl is a good idea or should I stay > on > centos as for my other images? FWIW: There already is an Alpine image for haproxy in Docker Official Images: https://github.com/docker-library/haproxy/blob/master/1.9/alpine/Dockerfile Personally I'm a Debian guy, for containers I prefer Debian based and CentOS / RHEL I don't use at all. > Any Idea for the other failed tests? No idea. Best regards Tim Düsterhus > - > ## Starting vtest ## > Testing with haproxy version: 1.9.2 > #top TEST ./reg-tests/http-rules/h2.vtc FAILED (0.859) exit=2 > #top TEST ./reg-tests/mailers/k_healthcheckmail.vtc FAILED (7.739) exit=2 > #top TEST ./reg-tests/log/b0.vtc TIMED OUT (kill -9) > #top TEST ./reg-tests/log/b0.vtc FAILED (10.001) signal=9 > #top TEST ./reg-tests/http-messaging/h2.vtc FAILED (0.752) exit=2 > 4 tests failed, 0 tests skipped, 29 tests passed > ## Gathering results ## > ## Test case: ./reg-tests/http-messaging/h2.vtc ## > ## test results in: > "/tmp/haregtests-2019-01-22_19-34-55.EKMMnc/vtc.3399.7739e83e" > c1h2 0.0 Wrong frame type HEADERS (1) wanted WINDOW_UPDATE > ## Test case: ./reg-tests/log/b0.vtc ## > ## test results in: > "/tmp/haregtests-2019-01-22_19-34-55.EKMMnc/vtc.3399.2776263d" > ## Test case: ./reg-tests/http-rules/h2.vtc ## > ## test results in: > "/tmp/haregtests-2019-01-22_19-34-55.EKMMnc/vtc.3399.0900be1e" > s10.0 EXPECT req.http.test3maskff (2001:db8:c001:c01a:::10:0) == > "2001:db8:c001:c01a:0::10:0" failed > ## Test case: ./reg-tests/mailers/k_healthcheckmail.vtc ## > ## test results in: > "/tmp/haregtests-2019-01-22_19-34-55.EKMMnc/vtc.3399.506e5b2b" > c27.0 EXPECT resp.http.mailsreceived (11) == "16" failed > - > >> Best regards >> Tim Düsterhus > > Regards > Aleks >
Re: haproxy 1.9.2 with boringssl
On Tue, Jan 22, 2019 at 11:45 AM Aleksandar Lazic wrote: > Can it be reused to test a specific server like? > > ssl/test/runner/runner -test "KeyUpdate-ToServer" 127.0.0.1:8443 Not easily: it drives the implementation under test by forking a process and has quite a complex interface via command-line arguments. (I.e. https://boringssl.googlesource.com/boringssl/+/eadef4730e66f914d7b9cbb2f38ecf7989f992ed/ssl/test/test_config.h) > or should be a small c/go program be used for that test? You could easily tweak transport_common.cc to call SSL_key_update before each SSL_write or so. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
Re: haproxy 1.9.2 with boringssl
Tim. Am 22.01.2019 um 20:26 schrieb Tim Düsterhus: > Aleks, > > Am 22.01.19 um 19:38 schrieb Aleksandar Lazic: >> ## test results in: >> "/tmp/haregtests-2019-01-22_18-28-24.aBghMD/vtc.3398.76167f9e" >> s10.0 EXPECT req.http.test3maskff (2001:db8:c001:c01a:::10:0) == >> "2001:db8:c001:c01a:0::10:0" failed > > The difference here is that the test expects an IPv6 address that's not > maximally compressed, while you get a IPv6 address that *is* maximally > compressed. I would guess that this is the difference in behaviour > between glibc and musl (as you are using an Alpine container). Ah that explains this error. This means that the function in haproxy works but the check should be adopted to match both cases, right? Do you think that in general the alpine/musl is a good idea or should I stay on centos as for my other images? Any Idea for the other failed tests? - ## Starting vtest ## Testing with haproxy version: 1.9.2 #top TEST ./reg-tests/http-rules/h2.vtc FAILED (0.859) exit=2 #top TEST ./reg-tests/mailers/k_healthcheckmail.vtc FAILED (7.739) exit=2 #top TEST ./reg-tests/log/b0.vtc TIMED OUT (kill -9) #top TEST ./reg-tests/log/b0.vtc FAILED (10.001) signal=9 #top TEST ./reg-tests/http-messaging/h2.vtc FAILED (0.752) exit=2 4 tests failed, 0 tests skipped, 29 tests passed ## Gathering results ## ## Test case: ./reg-tests/http-messaging/h2.vtc ## ## test results in: "/tmp/haregtests-2019-01-22_19-34-55.EKMMnc/vtc.3399.7739e83e" c1h2 0.0 Wrong frame type HEADERS (1) wanted WINDOW_UPDATE ## Test case: ./reg-tests/log/b0.vtc ## ## test results in: "/tmp/haregtests-2019-01-22_19-34-55.EKMMnc/vtc.3399.2776263d" ## Test case: ./reg-tests/http-rules/h2.vtc ## ## test results in: "/tmp/haregtests-2019-01-22_19-34-55.EKMMnc/vtc.3399.0900be1e" s10.0 EXPECT req.http.test3maskff (2001:db8:c001:c01a:::10:0) == "2001:db8:c001:c01a:0::10:0" failed ## Test case: ./reg-tests/mailers/k_healthcheckmail.vtc ## ## test results in: "/tmp/haregtests-2019-01-22_19-34-55.EKMMnc/vtc.3399.506e5b2b" c27.0 EXPECT resp.http.mailsreceived (11) == "16" failed - > Best regards > Tim Düsterhus Regards Aleks
Re: haproxy 1.9.2 with boringssl
Am 22.01.2019 um 20:30 schrieb Adam Langley: > On Tue, Jan 22, 2019 at 11:16 AM Aleksandar Lazic wrote: >> Agree that I get a 400 with this command. >> >> `echo 'K' | ./tool/bssl s_client -connect mail.google.com:443` > > (Note that "K" on its own line does not send a KeyUpdate message with > BoringSSL's bssl tool. It just sends "K\n".) > >> How does boringssl test if the KeyUpdate on a server works? > > If you're asking how BoringSSL's internal tests exercise KeyUpdates > then we maintain a fork of Go's TLS stack that is extensively modified > to be able to generate a large variety of TLS patterns. That is used > to exercise KeyUpdates in a number of ways: > https://boringssl.googlesource.com/boringssl/+/eadef4730e66f914d7b9cbb2f38ecf7989f992ed/ssl/test/runner/runner.go#2779 Thanks. Can it be reused to test a specific server like? ssl/test/runner/runner -test "KeyUpdate-ToServer" 127.0.0.1:8443 or should be a small c/go program be used for that test? > Cheers > > AGL Regards Aleks
Re: haproxy 1.9.2 with boringssl
On Tue, Jan 22, 2019 at 11:16 AM Aleksandar Lazic wrote: > Agree that I get a 400 with this command. > > `echo 'K' | ./tool/bssl s_client -connect mail.google.com:443` (Note that "K" on its own line does not send a KeyUpdate message with BoringSSL's bssl tool. It just sends "K\n".) > How does boringssl test if the KeyUpdate on a server works? If you're asking how BoringSSL's internal tests exercise KeyUpdates then we maintain a fork of Go's TLS stack that is extensively modified to be able to generate a large variety of TLS patterns. That is used to exercise KeyUpdates in a number of ways: https://boringssl.googlesource.com/boringssl/+/eadef4730e66f914d7b9cbb2f38ecf7989f992ed/ssl/test/runner/runner.go#2779 Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
Re: haproxy 1.9.2 with boringssl
Aleks, Am 22.01.19 um 19:38 schrieb Aleksandar Lazic: > ## test results in: > "/tmp/haregtests-2019-01-22_18-28-24.aBghMD/vtc.3398.76167f9e" > s10.0 EXPECT req.http.test3maskff (2001:db8:c001:c01a:::10:0) == > "2001:db8:c001:c01a:0::10:0" failed The difference here is that the test expects an IPv6 address that's not maximally compressed, while you get a IPv6 address that *is* maximally compressed. I would guess that this is the difference in behaviour between glibc and musl (as you are using an Alpine container). Best regards Tim Düsterhus
Re: haproxy 1.9.2 with boringssl
Am 22.01.2019 um 20:04 schrieb Adam Langley: > On Tue, Jan 22, 2019 at 10:54 AM Aleksandar Lazic wrote: >> Do have boringssl a similar tool like s_client? > > BoringSSL builds tool/bssl (in the build directory), which is similar. > However it doesn't have any magic inputs that can trigger a KeyUpdate > message like OpenSSL's s_client. Thanks. The test is already runnig as I got your answer. https://gitlab.com/aleks001/haproxy-19-boringssl/-/jobs/149540960 Agree that I get a 400 with this command. `echo 'K' | ./tool/bssl s_client -connect mail.google.com:443` How does boringssl test if the KeyUpdate on a server works? > Cheers > > AGL Regards Aleks
Re: haproxy 1.9.2 with boringssl
On Tue, Jan 22, 2019 at 10:54 AM Aleksandar Lazic wrote: > Do have boringssl a similar tool like s_client? BoringSSL builds tool/bssl (in the build directory), which is similar. However it doesn't have any magic inputs that can trigger a KeyUpdate message like OpenSSL's s_client. Cheers AGL
Re: haproxy 1.9.2 with boringssl
Am 22.01.2019 um 19:54 schrieb Aleksandar Lazic: > Cool, thanks. > > Do have boringssl a similar tool like s_client? > > I don't like to build openssl just for s_client call :-) Answer my own question. bssl is the boringssl tool command. The open question is why the tests fails in container? > Regards > Aleks > > > Ursprüngliche Nachricht > Von: Janusz Dziemidowicz > Gesendet: 22. Jänner 2019 19:49:15 MEZ > An: Aleksandar Lazic > CC: HAProxy > Betreff: Re: haproxy 1.9.2 with boringssl > > wt., 22 sty 2019 o 19:40 Aleksandar Lazic napisał(a): >> >> Hi. >> >> I have now build haproxy with boringssl and it looks quite good. >> >> Is it the recommended way to simply make a git clone without any branch or >> tag? >> Does anyone know how the KeyUpdate can be tested? > > openssl s_client -connect HOST:PORT (openssl >= 1.1.1) > Just type 'K' and press enter. If the server is broken then connection > will be aborted. > > www.github.com:443, currently broken: > read R BLOCK > K > KEYUPDATE > read R BLOCK > read:errno=0 > > mail.google.com:443, working: > read R BLOCK > K > KEYUPDATE > > >
Re: haproxy 1.9.2 with boringssl
Cool, thanks. Do have boringssl a similar tool like s_client? I don't like to build openssl just for s_client call :-) Regards Aleks Ursprüngliche Nachricht Von: Janusz Dziemidowicz Gesendet: 22. Jänner 2019 19:49:15 MEZ An: Aleksandar Lazic CC: HAProxy Betreff: Re: haproxy 1.9.2 with boringssl wt., 22 sty 2019 o 19:40 Aleksandar Lazic napisał(a): > > Hi. > > I have now build haproxy with boringssl and it looks quite good. > > Is it the recommended way to simply make a git clone without any branch or > tag? > Does anyone know how the KeyUpdate can be tested? openssl s_client -connect HOST:PORT (openssl >= 1.1.1) Just type 'K' and press enter. If the server is broken then connection will be aborted. www.github.com:443, currently broken: read R BLOCK K KEYUPDATE read R BLOCK read:errno=0 mail.google.com:443, working: read R BLOCK K KEYUPDATE
Re: haproxy 1.9.2 with boringssl
wt., 22 sty 2019 o 19:40 Aleksandar Lazic napisał(a): > > Hi. > > I have now build haproxy with boringssl and it looks quite good. > > Is it the recommended way to simply make a git clone without any branch or > tag? > Does anyone know how the KeyUpdate can be tested? openssl s_client -connect HOST:PORT (openssl >= 1.1.1) Just type 'K' and press enter. If the server is broken then connection will be aborted. www.github.com:443, currently broken: read R BLOCK K KEYUPDATE read R BLOCK read:errno=0 mail.google.com:443, working: read R BLOCK K KEYUPDATE -- Janusz Dziemidowicz
