пн, 17 июл. 2023 г. в 11:58, William Lallemand <wlallem...@haproxy.com>:
> 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. > BoringSSL is "rolling releases only" while aws-lc has stable releases. there's work in progress how to cache aws-lc build (I guess only couple of small issues still exist) [PATCH] Minor: ssl: Build with new cryptographic library AWS-LC by andrewhop · Pull Request #1 · andrewhop/haproxy (github.com) <https://github.com/andrewhop/haproxy/pull/1> I'm fine with either scheduled or "on push" CI checks, no particular opinion from my side. also, if "aws-lc" is somewhat very similar to openssl-1.1.1, we do not expect we'll catch a lot of build errors daily because we already run builds against openssl-1.1.1, maybe weekly CI would be enough. > > 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 > >
