Thanks for the tip, I got the CI running and it found a minor visibility issue
that we had to fix with our shared build [1]. All but one test [2] is now
passing in the HAProxy CI while they all pass locally. Do you have any
suggestions/tips for debugging this test?
Also the compiler and/or options used in your CI turned a warning into an error
so I had to update the patch slightly to use the correct callback type for
modern libcryptos.
src/ssl_sock.c:1183:43: error: passing argument 2 of
‘SSL_CTX_get_tlsext_status_cb’ from incompatible pointer type
[-Werror=incompatible-pointer-types]
1183 | SSL_CTX_get_tlsext_status_cb(ctx, &callback);
| ^~~~~~~~~
| |
| void (**)(void)
compilation terminated due to -Wfatal-errors.
OpenSSL >= 1.1.1 have the same callback signature as AWS-LC: int
(*callback)(SSL *, void *). I believe this works with OpenSSL >= 1.1.1. because
their SSL_CTX_ctrl performs the cast while AWS-LC has a dedicated function
SSL_CTX_get_tlsext_status_cb with the right type.
[1] https://github.com/aws/aws-lc/pull/1091
[1]
https://github.com/andrewhop/haproxy/actions/runs/5537027817/jobs/10105411198?pr=1#step:15:215
From: Илья Шипицин <chipits...@gmail.com>
Sent: Wednesday, July 12, 2023 12:53 AM
To: Hopkins, Andrew
Cc: 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.
Hello, Andrew!
you already tried to launch CI in fork [PATCH] Minor: ssl: Build with new
cryptographic library AWS-LC by andrewhop · Pull Request #1 · andrewhop/haproxy
(github.com)
please make sure you've enabled GHA for fork (here: Actions · andrewhop/haproxy
(github.com))
also, current trigger is set to "push"
haproxy/.github/workflows/vtest.yml at master · andrewhop/haproxy · GitHub
I'd try
on: [ push, pull_request, workflow_dispatch ]
ср, 12 июл. 2023 г. в 02:29, Hopkins, Andrew <and...@amazon.com>:
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
[1] https://github.com/aws/aws-lc
[2] https://github.com/aws/aws-lc/pull/1054
[3] https://github.com/aws/aws-lc/pull/1071
[4] 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
[6] https://github.com/awslabs/s2n-bignum
From e7b7c10af4dd9ac96d5f7d1d8528c345e979b218 Mon Sep 17 00:00:00 2001
From: Andrew Hopkins <and...@amazon.com>
Date: Thu, 6 Jul 2023 15:41:46 -0700
Subject: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC
This adds documentation on how to use AWS-LC when building HAProxy
and updates the GitHub runners to test with AWS-LC.
Update the type of the OCSP callback retrieved with
SSL_CTX_get_tlsext_status_cb with the actual type for
libcrypto versions greater than 1.0.2. This doesn't affect
OpenSSL which casts the callback to void* in SSL_CTX_ctrl.
---
.github/matrix.py | 1 +
INSTALL | 12 ++++++------
scripts/build-ssl.sh | 21 +++++++++++++++++++++
src/ssl_sock.c | 4 ++++
4 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/.github/matrix.py b/.github/matrix.py
index 7f22c43bb..da7d143f7 100755
--- a/.github/matrix.py
+++ b/.github/matrix.py
@@ -177,6 +177,7 @@ for CC in ["gcc", "clang"]:
"OPENSSL_VERSION=1.1.1s",
"QUICTLS=yes",
# "BORINGSSL=yes",
+ 'AWS_LC=yes',
]
if "haproxy-" not in ref_name:
diff --git a/INSTALL b/INSTALL
index 622fcc098..5e51acef2 100644
--- a/INSTALL
+++ b/INSTALL
@@ -244,12 +244,12 @@ https://github.com/openssl/openssl/issues/17627). If a migration to 3.x is
mandated by support reasons, at least 3.1 recovers a small fraction of this
important loss.
-Three OpenSSL derivatives called LibreSSL, BoringSSL and QUICTLS are reported
-to work as well. While there are some efforts from the community to ensure they
-work well, OpenSSL remains the primary target and this means that in case of
-conflicting choices, OpenSSL support will be favored over other options. Note
-that OpenSSL is not compatible when building haproxy with QUIC support. In this
-case, QUICTLS is the preferred alternative. As of writing this, the QuicTLS
+Four OpenSSL derivatives called LibreSSL, BoringSSL, QUICTLS, and AWS-LC are
+reported to work as well. While there are some efforts from the community to
+ensure they work well, OpenSSL remains the primary target and this means that in
+case of conflicting choices, OpenSSL support will be favored over other options.
+Note that OpenSSL is not compatible when building haproxy with QUIC support. In
+this case, QUICTLS is the preferred alternative. As of writing this, the QuicTLS
project follows OpenSSL very closely and provides update simultaneously, but
being a volunteer-driven project, its long-term future does not look certain
enough to convince operating systems to package it, so it needs to be build
diff --git a/scripts/build-ssl.sh b/scripts/build-ssl.sh
index a1935dd1e..26ce1c72c 100755
--- a/scripts/build-ssl.sh
+++ b/scripts/build-ssl.sh
@@ -86,6 +86,17 @@ download_boringssl () {
fi
}
+download_aws_lc () {
+ if [ ! -d "download-cache/aws-lc" ]; then
+ git clone --depth=1 https://github.com/aws/aws-lc.git download-cache/aws-lc
+ else
+ (
+ cd download-cache/aws-lc
+ git pull
+ )
+ fi
+}
+
download_quictls () {
if [ ! -d "download-cache/quictls" ]; then
git clone --depth=1 https://github.com/quictls/openssl download-cache/quictls
@@ -132,6 +143,16 @@ if [ ! -z ${BORINGSSL+x} ]; then
)
fi
+if [ ! -z ${AWS_LC+x} ]; then
+ download_aws_lc
+ cd download-cache/aws-lc
+ if [ -d build ]; then rm -rf build; fi
+ mkdir build
+ cd build
+ cmake -GNinja -DCMAKE_BUILD_TYPE=release -DBUILD_SHARED_LIBS=1 -DDISABLE_GO=1 -DDISABLE_PERL=1 -DCMAKE_INSTALL_PREFIX=${HOME}/opt ..
+ ninja install
+fi
+
if [ ! -z ${QUICTLS+x} ]; then
(
download_quictls
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 9f48483d9..39099af2c 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -1112,7 +1112,11 @@ static int ssl_sock_load_ocsp(const char *path, SSL_CTX *ctx, struct ckch_data *
char *warn = NULL;
unsigned char *p;
#ifndef USE_OPENSSL_WOLFSSL
+#if (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L)
+ int (*callback) (SSL *, void *);
+#else
void (*callback) (void);
+#endif
#else
tlsextStatusCb callback;
#endif
--
2.34.1
