сб, 15 июл. 2023 г. в 10:44, Willy Tarreau <w...@1wt.eu>:
> 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.
>
I tried to build with USE_QUIC=1:
[ilia@fedora haproxy]$ sh go.sh
CC src/quic_conn.o
CC src/h3.o
CC src/xprt_quic.o
CC src/quic_frame.o
CC src/quic_tls.o
In file included from src/quic_conn.c:60:
include/haproxy/quic_tls.h: In function ‘tls_aead’:
include/haproxy/quic_tls.h:124:14: error: ‘TLS1_3_CK_AES_128_GCM_SHA256’
undeclared (first use in this function); did you mean
‘TLS1_CK_AES_128_GCM_SHA256’?
124 | case TLS1_3_CK_AES_128_GCM_SHA256:
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| TLS1_CK_AES_128_GCM_SHA256
compilation terminated due to -Wfatal-errors.
make: *** [Makefile:998: src/quic_conn.o] Error 1
make: *** Waiting for unfinished jobs....
[ilia@fedora haproxy]$
>
> > > * 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
>
>
