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
