Hi Andrew.
Thank you for your answers.
On 2023-07-13 (Do.) 08:22, Hopkins, Andrew wrote:
Hi Alex, thanks for taking a look at this change, to answer your questions:
* Do you plan to make releases which stable ABI on that we can rely on?
Yes, we have releases on GitHub that follow semantic versioning and
within minor versions everything is backward compatible. Internal
details of structs may change in an API compatible way over time but
might not be ABI. This would be signaled in the release notes and
version number.
Okay.
* Do you plan to add quic (Server part) faster then OpenSSL?
I have not looked into quic benchmarks but it uses the same
cryptographic primitives as TLS so I imagine we'd be faster for a lot of
the algorithms. It might not be useful for HAProxy which is all C, but
AWS also launched s2n-quic [1] which does have extensive testing for
correctness and performance. s2n-quic evenuses AWS-LC's libcrypto for
all of the cryptographic operations [2] though our rust bindings
aws-lc-rs [3].
Hm, this implies a dependency for rust which increases the complexity to
build HAProxy. From my point of view isn't this very helpfull to bring
the library into haproxy.
* Will be there some packages for debian/ubuntu/RHEL/... so that the
users of HAProxy can "just install and run" HAProxy with that SSL Lib?
In the near future no. Currently AWS-LC does not support enough packages
to fully replace libcrypto for the entire operating system, and
balancing different programs using different library paths and libcrypto
implementations is tricky. Eventually distributing static archives and
shared libraries once we have more support makes sense. There is more
context/history in this issue [4].
Uh that's a show stopper, at least from my point of view. This implies
the same work as HAProxy team have for wolfssl, BoringSSL and quictls
and that's a lot of work.
As the patch looks quite small and AWS-LC relies on BoringSSL are you
handle the BoringSSL chnanges so that the API and not often ABI changes
are handled by AWS-LC?
[1] https://github.com/aws/s2n-quic
[2] https://github.com/aws/s2n-quic/pull/1840
[3] https://github.com/aws/aws-lc-rs
[4] https://github.com/aws/aws-lc/issues/804
Thanks, Andrew
------------------------------------------------------------------------
*From:* Aleksandar Lazic <al-hapr...@none.at>
*Sent:* Wednesday, July 12, 2023 1:14 AM
*To:* Hopkins, Andrew; haproxy@formilux.org
*Subject:* RE: [EXTERNAL][PATCH] BUILD: ssl: Build with new
cryptographic library AWS-LC
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and
know the content is safe.
Hi Andrew.
On 2023-07-12 (Mi.) 02:26, 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
<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.
Sounds quite interesting library.
I have a few questions about the future plans of the library.
* Do you plan to make releases which stable ABI on that we can rely on?
That's one of the pain points with BoringSSL.
* Do you plan to add quic (Server part) faster then OpenSSL?
* Will be there some packages for debian/ubuntu/RHEL/... so that the
users of HAProxy can "just install and run" HAProxy with that SSL Lib?
Thanks, Andrew
Regards
Alex
[1] https://github.com/aws/aws-lc <https://github.com/aws/aws-lc>
[2] https://github.com/aws/aws-lc/pull/1054
<https://github.com/aws/aws-lc/pull/1054>
[3] https://github.com/aws/aws-lc/pull/1071
<https://github.com/aws/aws-lc/pull/1071>
[4] https://github.com/aws/aws-lc/pull/1083
<https://github.com/aws/aws-lc/pull/1083>
[5]
https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance
<https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance>
[6] https://github.com/awslabs/s2n-bignum
<https://github.com/awslabs/s2n-bignum>
