Hi Marcin, On 3/7/19 6:43 PM, Marcin Deranek wrote: > Hi, > > On 3/6/19 6:36 PM, Emeric Brun wrote: >> According to the documentation: >> >> ssl-mode-async >> Adds SSL_MODE_ASYNC mode to the SSL context. This enables asynchronous TLS >> I/O operations if asynchronous capable SSL engines are used. The current >> implementation supports a maximum of 32 engines. The Openssl ASYNC API >> doesn't support moving read/write buffers and is not compliant with >> haproxy's buffer management. So the asynchronous mode is disabled on >> read/write operations (it is only enabled during initial and reneg >> handshakes). >> >> Asynchronous mode is disabled on the read/write operation and is only >> enabled during handshake. >> >> It means that for the ciphering process the engine will be used in blocking >> mode (not async) which could result to >> unpredictable behavior on timers because the haproxy process will >> sporadically fully blocked waiting for the engine. >> >> To avoid this issue, you should ensure to use QAT only for the asymmetric >> computing algorithm (such as RSA DSA ECDSA). >> and not for ciphering ones (AES and everything else ...) > > I did explicitly enabled RSA algos: > > ssl-engine qat algo RSA > > and errors were gone at that point. Unfortunately all QAT activity too as > > /sys/kernel/debug/qat_c6xx_0000\:0*/fw_counters > > were reporting identical values (previously they were incrementing). > > I did explicitly enforce RSA: > > ssl-default-server-ciphers ECDHE-RSA-AES256-GCM-SHA384
I've just realized that if your server are TLSv1.3 ssl-default-server-ciphers won't force anything (see ssl-default-server-ciphersuites documentation) R, Emeric
