On 3/11/19 11:51 AM, Emeric Brun wrote: > On 3/11/19 11:06 AM, Marcin Deranek wrote: >> Hi Emeric, >> >> On 3/8/19 11:24 AM, Emeric Brun wrote: >>> Are you sure that servers won't use ECDSA certificates? Do you check that >>> conn are successful forcing 'ECDHE-RSA-AES256-GCM-SHA384' >> >> Backend servers only support TLS 1.2 and RSA certificates. >> >>> Could you check algo supported by QAT doing this ?: >>> openssl engine -c qat >> >> # /opt/booking-openssl/bin/openssl engine -c qat >> (qat) Reference implementation of QAT crypto engine >> [RSA, DSA, DH, AES-128-CBC-HMAC-SHA1, AES-128-CBC-HMAC-SHA256, >> AES-256-CBC-HMAC-SHA1, AES-256-CBC-HMAC-SHA256, TLS1-PRF] >> >>> Could you retry with this config: >>> ssl-engine qat algo RSA,DSA,EC,DH >> >> Just did that and experienced the very same effect: no QAT activity for >> backend server healthchecks :-( When I add frontend eg. >> >> frontend frontend1 >> bind 127.0.0.1:8443 ssl crt >> /etc/lb_engine/data/generated/ssl/10.252.24.7:443 >> default_backend pool_all >> >> and make some connections/requests (TLS1.2 and/or TLS/1.3) to the frontend I >> see QAT activity, but *NO* activity when HAProxy is "idle" (only doing >> healthchecks to backend servers: TLS 1.2 only). >> This feels like healthchecks are not passing through QAT engine for whatever >> reason :-( Even enabling HTTP check for the backend (option httpchk) does >> not make any difference. >> The question: Is SSL Async Mode actually supported on the backend side >> (either healthchecks and/or normal traffic) ? >> Regards, > > Mode async is enabled on both sides, server and frontend side. > > But on server side, haproxy is using session resuming, so there is a new key > computation (full handshake with RSA/DSA computation) only every 5 minutes > (openssl default value). > > You can force to recompute each time setting "no-ssl-reuse" on server line, > but it will add a heavy load for ssl computation on the server. > > > R, > Emeric >
I've just realized that what you observe is the expected behavior: QAT offloads on the frontend side, and this is what we want: to offload on QAT the heavy load of key computing on the frontend side (the support of async engines in haproxy was added for this reason). On the backend side, haproxy acts as a client, re-using session and even if a key is re-computed by the server, the cost of processing on the haproxy's backend side is much lower compared to frontend side, perhaps it is not even implemented into QAT. Once again, you could add the "no-ssl-reuse" statement if you want to check if QAT offloads the backend side, but it is clearly not an optimal option for production because it will generate an heavy load on your servers and force them to recompute keys for each connections. R, Emeric
