Willy you're correct. AWS-LC does have support for the QUIC primitives HAProxy  
needs, we just need to fix some of the names [1] in either HAProxy's code or 
AWS-LC in a follow up change. 

To Alex's concern on API compatibility: yes AWS-LC is aiming to provide a more 
stable API. We already run integration tests with 6 other projects [2] 
including HAProxy. This will help ensure API compatibility going forward.  What 
is your specific concern with ABI compatibility? Are you looking to take the 
haproxy executable built with OpenSSL libcrypto/libssl and drop in AWS-LC 
without recompiling haproxy? Or do that between AWS-LC libcrypto/libssl 
versions?

Willy that's an interesting idea for library name conflict avoidance. I did not 
know that's how quictls solved this problem, it seems like it would work for 
simple applications with only one dependency on libcrypto (such as HAProxy). 
However, I don't think it would solve the issue of transitive dependencies 
mixing libcrypto implementations, e.g. an application depends on 2 libraries 
that each depend on libcrypto, if one library moves to AWS-LC the application 
will get symbol conflicts.

[1] 
https://github.com/haproxy/haproxy/blob/master/include/haproxy/quic_tls-t.h#L28
[2] https://github.com/aws/aws-lc/tree/main/tests/ci/integration


On 7/15/23, 1:41 AM, "Willy Tarreau" <w...@1wt.eu <mailto:w...@1wt.eu>> wrote:


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 Alex, Andrew,


On Thu, Jul 13, 2023 at 11:54:44AM +0200, Aleksandar Lazic wrote:
> On 2023-07-13 (Do.) 08:22, Hopkins, Andrew wrote:
> > * 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.


I think there was a misunderstanding between you two above. I understand
Alex' question as "will you merge quic support soon", but my understanding
last time I had the opportunity to discuss about AWS-LC was that it *is*
already there. Alex, what Andrew mentioned above is that their own QUIC
implementation, s2n-quic, uses their rust bindings, but we don't need
s2n-quic (since we have our own stack) and this will not add any
dependency.


> > * 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.


I think that what would be important would be to find a package maintainer
willing to maintain this into a distro for the whole maintenance life cycle
of that distro. It also helps a lot in designing stable and durable APIs
that boost adoption, because the early maintenance trouble are quickly
learned during backports and everyone is more careful over time.


One thing that should really be avoided would be to name the library as
the regular openssl one, because while it helps with *early* adoption,
it complicates everything over time and for all packages. For example,
quictls adopted the .81 suffix (81 for "Q") and as such there's no
conflict on the shared lib. For building, it's as simple as passing the
SSL_INC/SSL_LIB during the build (and basically all software supporting
openssl support this), so there's no trouble either, and all libs can
coexist on the same distro. But yeah, it's really important to find
someone willing to maintain such a package long enough for a distro,
that fills a hole that the whole world is waiting to be plugged (since
we know it will not come from openssl anyway).


The partial support from various software is not a problem as long as
openssl and aws-lc can coexist on the system. Some will just be built
with one and others with the other. This has always existed and I would
be surprised if there's no software linked against GNUtls on distros
that ship it for example. So if aws-lc enters say, debian and ubuntu
LTS, and common software like curl, apache, nginx, ngtcp2, haproxy can
build with it, we'll basically have what users are waiting for to fully
enable QUIC, and with a lib that cares about performance. For now there
is only wolfSSL in that place, and while it works pretty well, it
requires more porting effort from applications and a sensible set of
build settings still needs to be defined for distros. In any case, the
more options for package maintainers, the better.


Regards,
Willy



Reply via email to