another significant thing is developer velocity, 4 min for supplementary
lib build is too high.
[image: image.png]
can we implement something like current openssl (i.e. taking the last
available tag, which is even easier because aws-lc uses semantic versioning)
@functools.lru_cache(5)
def determine_latest_openssl(ssl):
headers = {}
if environ.get("GITHUB_TOKEN") is not None:
headers["Authorization"] = "token
{}".format(environ.get("GITHUB_TOKEN"))
request = urllib.request.Request(
"https://api.github.com/repos/openssl/openssl/tags";, headers=headers
)
try:
openssl_tags = urllib.request.urlopen(request)
except:
return "OPENSSL_VERSION=failed_to_detect"
tags = json.loads(openssl_tags.read().decode("utf-8"))
latest_tag = ""
for tag in tags:
name = tag["name"]
if "openssl-" in name:
if name > latest_tag:
latest_tag = name
return "OPENSSL_VERSION={}".format(latest_tag[8:])
in such case we can enable github cache and lib won't be rebuilt every time
чт, 13 июл. 2023 г. в 08:25, Hopkins, Andrew <and...@amazon.com>:
> 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.
>
> * 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 even uses AWS-LC's libcrypto for all of the
> cryptographic operations [2] though our rust bindings aws-lc-rs [3].
>
>
> * 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].
>
>
>
> [1] https://github.com/aws/s2n-quic
> [2] https://github.com/aws/s2n-quic/pull/1840
> <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 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
> > [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
> >
> >
>
