Hello,
I'm trying to understand `ssl_fc_has_early` fetcher behavior as I'm
unable to find a single request where it returns 1.
Our config has 0rtt enabled and it is as follow:
```
global
log 127.0.0.1 format rfc5424 local0 info
daemon
stats socket /var/lib/haproxy/stats level admin mode 600 user
haproxy group haproxy expose-fd listeners
stats timeout 2m
maxconn 524288
user haproxy
group haproxy
set-dumpable
tune.bufsize 33792
tune.runqueue-depth 1200
tune.sched.low-latency on
tune.ssl.cachesize 0
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11
ssl-default-bind-ciphers
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384
ssl-default-bind-ciphersuites
TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11
ssl-default-server-ciphers
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES256-SHA
ssl-default-server-ciphersuites
TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
ssl-server-verify none
hard-stop-after 183s
nbthread 16
cpu-map auto:1/1-16 0-15
spread-checks 5
chroot /etc/haproxy/chroot
strict-limits
defaults
mode http
log global
option httplog
option http-keep-alive
option forwardfor except 127.0.0.0/8
option redispatch 1
option http-ignore-probes
retries 3
retry-on conn-failure empty-response response-timeout 0rtt-rejected
timeout http-request 10s
timeout queue 1s
timeout connect 10s
timeout client 300s
timeout server 300s
timeout http-keep-alive 10s
timeout check 5s
maxconn 524288
balance roundrobin
http-reuse always
default-server inter 10s fastinter 1s fall 3 slowstart 20s observe
layer7 error-limit 5 on-error fastinter pool-purge-delay 10s tfo
allow-0rtt pool-low-conn 32
http-check expect rstatus ^(200|429)
frontend fe_foo
bind x:80 name http_ip process 1/all tfo
bind x:443 name https_ip process 1/all ssl crt
/etc/haproxy/tls/fe_foo alpn h2,http/1.1 tfo allow-0rtt
log-format-sd [fc_rtt=\"%[fc_rtt]\"\
fc_0rtt=\"%[ssl_fc_has_early]\"\ fc_resumed=\"%[ssl_fc_is_resumed]\"]
http-request disable-l7-retry if ! METH_GET
http-request wait-for-handshake if ! METH_GET
use_backend bar
```
- Am I right that tune.ssl.cachesize is not involved here?
- What's odd is that I do find requests which returns 1 with
`ssl_fc_is_resumed` fetcher.
- I looked at `ssl_fc_has_early` and I did not found anything strange.
- I tried to remove `wait-for-handshake` and `tune.ssl.cachesize 0`
without success
>From the client point of view I'm able to test it through:
openssl s_client -tls1_3 -state -connect x:443 -servername foo.com
-keylogfile keylogfile.log -sess_out ~/ssl/session.data
openssl s_client -tls1_3 -state -connect x:443 -servername foo.com
-keylogfile keylogfile.log -sess_in ~/ssl/session.data -early_data
httpget.txt
The second time I'm able to see:
Reused, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was accepted
Verify return code: 0 (ok)
So to me, from the client point of view I'm able to make use of 0rtt.
Any idea how to explain `ssl_fc_has_early` fetcher behaviour? Am I
missing something in my config? Does someone have a different
behaviour with a similar config?
Best,
--
William
