I have good news and bad news. The good news is I figured out why some of the HAProxy tests in AWS-LC’s CI were getting a different result than the HAProxy tests in your CI, I’ve fixed that in this PR [1] by installing more test dependencies (socat and lua). The bad news is I need to skip ssl_dh.vtc in HAProxy’s CI [2] for now. AWS-LC does not support any FFDH ciphersuites in our libssl, but we do support the operations in our libcrypto. The cipher suites we do support are: TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_PSK_WITH_AES_128_CBC_SHA TLS_PSK_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
[1] https://github.com/aws/aws-lc/pull/1097 [2] https://github.com/andrewhop/haproxy/pull/1/files#diff-0b21de6f7e1d44cc39f76a8d90c65fc0edbe75fd5327a20cfc9f45c79925e66b From: Илья Шипицин <chipits...@gmail.com> Date: Saturday, July 15, 2023 at 1:30 PM To: "Hopkins, Andrew" <and...@amazon.com> Cc: "haproxy@formilux.org" <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. Andrew, I could not find how to enable "DHE-RSA-AES256-GCM-SHA384" on aws-lc (required by haproxy vtest) *** h3 debug|[ALERT] (7370) : config : Proxy 'ssl-dhfile-lst': unable to set SSL cipher list to 'DHE-RSA-AES256-GCM-SHA384' for bind '/tmp/haregtests-2023-07-14_19-06-01.w4q6ak/vtc.6061.2c564146/ssl_dhfile.sock' at [/tmp/haregtests-2023-07-14_19-06-01.w4q6ak/vtc.6061.2c564146/h3/cfg:26]. *** h3 debug|Proxy 'ssl-dhfile-lst': unable to set SSL cipher list to 'DHE-RSA-AES256-GCM-SHA384' for bind '/tmp/haregtests-2023-07-14_19-06-01.w4q6ak/vtc.6061.2c564146/ssl_dhfile.sock' at [/tmp/haregtests-2023-07-14_19-06-01.w4q6ak/vtc.6061.2c564146/h3/cfg:26]. *** h3 debug|[ALERT] (7370) : config : Fatal errors found in configuration. ср, 12 июл. 2023 г. в 02:29, Hopkins, Andrew <and...@amazon.com<mailto: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
