Hi @wlallemand
Thank you for bringing this to our attention. I think we need to do some internal discussion. For example, not sure how this would affect our internal testing infrastructure. Please stay tuned.
Warm regards, Anthony

Hello @wlallemand ,

So I don't want to split hairs here, but the default configuration is

./configure

So, when a distribution uses --enable-distro they are already no longer doing the "defualt". They are also going to need to add a prefix as well. Would it be too much to ask them to also add --enable-haproxy and/or --enable-quic if they want it?

Respectfully, Anthony

I get your point, but distribution maintainers tend to minimize the build option they use, because they want to use what is recommended by the project. For HAProxy packages in ubuntu/debian we had to set some options by default directly in the project because it didn't make sense for the packagers to add options that diverged from the default build.

I don't know why they are building with --enable-distro but from what I'm reading in the documentation it "Enable wolfSSL distro build." so we can presume that is supposed to be used for packaging in distributions? Maybe I misunderstand but that what I thought.

If you have to add every single build option of wolfssl in the package build script it's quickly unmaintainable. The build options of WolfSSL are complex and it's difficult to chose them without being an expert on the subject.

The packages in a distribution are kind of a storefront, it's better to put shiny features so people can see them! The QUIC feature is a major asset compared to openssl which doesn't include the feature for example.

If you don't activate a maximum of options in the distribution, the package is pretty useless in a lot of cases and people would still have to maintain their wolfssl build. It would be beneficial for the wolfSSL project to have a maximum of features activated in major distributions, so projects that want to use it only have to link with it. Nobody wants to maintain an SSL package in addition to their project. When you want to provide 3rd party packages, you try to only package your project and rely on the distribution for the dependencies.

Hi @wlallemand ,

you make eloquent arguments and I don't disagree with any of your points at all.

... they want to use what is recommended by the project.

I fully agree. As such, I as a single developer, a member of a wider organization, need to go back to my team to see if we actually do recommend these settings. please allow me some time to organize some internal communications. You will hear back from me early next we here.

Warm regards, Anthony

I know that changing default options could be challenging from an organization point of view, thanks for taking the time to handle this!

Regards,

Now that #6841 has gone into master, I've checked and

./configure --enable-distro --enable-haproxy --enable-quic
make clean all check

...no longer fails.
I will now proceed to make --enable-distro pull in --enable-haproxy and --enable-quic
Please stay tuned.

Thanks for the feedback! By the way, the next ubuntu LTS will be frozen at the end of february 2024. It would be great if a new release is done with that before this date, so the package could be updated, or we would be stuck for another 2 years without this unfortunately :/

Hi @wlallemand ,

Can you provide some sort of assurance that if this work is completed soon, Ubuntu will take wolfssl?

WolfSSL is already packaged in ubuntu https://packages.ubuntu.com/search?searchon=sourcenames&keywords=wolfssl . However it's not up to date with the 5.6.4 version. I'm not part of the ubuntu project and can't guarantee they will pick this version unfortunately. It's possible that it is already too late :/

It looks like the 5.6.4 version is already in debian experimental, but not in debian sid, that's probably the reason why it's not there yet.

https://packages.debian.org/search?keywords=wolfssl&searchon=names&suite=all&section=all

It looks like 5.6.4 landed in the next ubuntu and debian:

• https://packages.ubuntu.com/source/noble/wolfssl
• https://packages.debian.org/sid/libwolfssl-dev

Well, this is great news!! Thank you for letting us know @wlallemand

@wlallemand ,

if you look at our latest on master, --enable-distro now brings in QUIC, but not HAPROXY. This is due to HAPROXY needing secure renegotiation. We don't feel --enable-distro should enable secure renegotiation.

Let me know if this makes sense to you.

Warm regards, Anthony

I don't see any reason for this to be needed by haproxy by default, we even set SSL_OP_NO_RENEGOTIATION in the SSL_CTX initilization with OpenSSL. And It's really not something which is recommended by default indeed.

@anhu could the secure renegociation be disabled in --enable-haproxy so we can have haproxy by default?

An interesting proposal. You're saying for HAPROXY, we can leave secure renegotiation disabled. Please stay tuned. I will have a chat with my colleagues.

Hello, Any update on this?

Hello @anhu, is something blocking this? We don't really have specific features in haproxy.

I thought since so much time has passed, interest in this had been lost. Let me take another pass at this.

@wlallemand , it appears HAProxy calls the APIs that are used for Secure Renegotiation.

  LD      haproxy
/usr/bin/ld: src/ssl_sock.o: in function `ssl_sock_to_buf':
/home/runner/work/wolfssl/wolfssl/build-dir/haproxy-v3.1.0/src/ssl_sock.c:5835: undefined reference to `wolfSSL_SSL_renegotiate_pending'
/usr/bin/ld: src/ssl_sock.o: in function `ssl_sock_handshake':
/home/runner/work/wolfssl/wolfssl/build-dir/haproxy-v3.1.0/src/ssl_sock.c:5262: undefined reference to `wolfSSL_SSL_renegotiate_pending'
/usr/bin/ld: /home/runner/work/wolfssl/wolfssl/build-dir/haproxy-v3.1.0/src/ssl_sock.c:5280: undefined reference to `wolfSSL_SSL_renegotiate_pending'
/usr/bin/ld: src/ssl_sock.o: in function `ssl_sock_from_buf':
/home/runner/work/wolfssl/wolfssl/build-dir/haproxy-v3.1.0/src/ssl_sock.c:5999: undefined reference to `wolfSSL_SSL_renegotiate_pending'
collect2: error: ld returned 1 exit status
make: *** [Makefile:1040: haproxy] Error 1

@anhu When WolfSSL is built without the Secure Renegotiation it simply ignores any renegotiation?

HAProxy uses SSL_OP_NO_RENEGOTIATION when acting as an SSL server, but still handles renegotiation received from the server when acting as a client.

If WolfSSL ignores the renegotiation, It is safe to add a #ifdef around the SSL_renegotiate_pending() if this the API is not available. I'll make the change in our code.

We already have a #define in our code in fact:

#ifndef SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION   /* needs OpenSSL >= 0.9.7 */
#define SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION 0
#define SSL_renegotiate_pending(arg) 0
#endif

We could do the same with WolfSSL but what constant could we check to determine that WolfSSL does not have this feature?

This commit should allow you to build without the API.

Wow @wlallemand !! Thank you. I'll need to figure out how to bring this into our CI system which will require help from my colleagues. Please stay tuned.
Warm regards, Anthony

Looking at this https://github.com/wolfSSL/wolfssl/blob/master/.github/workflows/haproxy.yml#L50 it seems like your CI only testing HAProxy v3.1.0. In my opinion you should check the 3.1 branch instead of just the v3.1.0 tag, or you could just check the HAProxy master branch directly.

If you want to test the 3.1 branch, it's not on github unfortunately, we handle the stable branch separately there https://git.haproxy.org/?p=haproxy-3.1.git. But I'll backport the patch to the 3.1 branch just in case.

I missed the warning about the macro already defined in wolfssl with renegotiation disabled, that's fixed with the patch above. And backported to the 3.1 branch. (I tested with your PR)

hello @wlallemand ....Sorry, this keeps falling off my radar. Is there a github haproxy branch I should test against?

Hello @anhu, only the master branch is available on github: https://github.com/haproxy/haproxy/tree/master