On Wed, Jul 12, 2023 at 12:26:06AM +0000, Hopkins, Andrew wrote: > Hello HAProxy maintainers, I work on the AWS libcrypto (AWS-LC) > project [1]. Our goal is to improve the cryptography we use internally > at AWS and help our customers externally. In the spirit of helping > people use good crypto we know it’s important to make it easy to use > AWS-LC everywhere they use cryptography. This is why we are interested > in integrating AWS-LC into HAProxy. > > AWS-LC is a fork of BoringSSL which you already partially support. We > recently merged in several PRs (Full OCSP support [2] and custom > extension support [3]) to fully support HAProxy the same as OpenSSL. > To ensure we continue to support HAProxy long term we added HAProxy > built with AWS-LC to our CI [4]. > > In our early testing we see modest improvements in overall throughput > when compared to OpenSSL 3.1 on x86 and arm CPUs. Following a similar > setup as this blog [5] I observe a small (~2.5%) increase in requests > per second for 5 kb requests on a C6i (x86) and C6g (arm) instance > using TLS 1.3 and AES 256 GCM. For both tests I used `taskset -c 2-47 > ./h1load -e -ll -P -t 46 -s 30 -d 120 -c 500 https://[c6i or c6g > ip]:[aws-lc or openssl port]/?s=5k`. > > This small difference in this symmetric crypto workload comes down to > AWS-LC and OpenSSL having similar AES implementations. We observe > larger performance improvements with our micro-benchmarks for > algorithms related to the TLS handshake such as 15% reduction for ECDH > with P-256, and 40% reduction for P-521 on a C6i. This comes from our > s2n-bignum library[6], a formally verified bignum library with a focus > on performance and correctness. > > When built with AWS-LC all current regression tests pass. I have > included a small patch to update your documentation with AWS-LC as an > option and I attempted to add AWS-LC to your CI. I need a little help > figuring out how to test that part. Lastly from your excellent > contributing guide I am not subscribed so I would like to be cc’d on > all responses. > > Thanks, Andrew >
Hello Andrew, That's interesting and we are open to new libraries that can give us a good alternative to OpenSSL. However the CI is becoming quite slow and we'd rather not add a new build for each push. I don't really like the fact that the patch is based on the git master for the push, the CI principally used to check if we didn't break anything in haproxy, so if the library keep changing during haproxy development it's more difficult to know if a breakage is because of haproxy or because of the library. We stopped building BoringSSL on the CI because of this, because there wasn't any clear maintainenance cycle and the library kept changing. It looks like you have real releases in awc-ls though. What I suggest is that we create a scheduled build for aws-lc like we've done with https://github.com/haproxy/haproxy/blob/master/.github/workflows/openssl-nodeprecated.yml for example. This way we don't increase the CI build for each push, and using the master branch don't become a problem. Regards, -- William Lallemand
