-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[lighttpd] -mod-wolfssl inhibited by missing library functionality #14142
Comments
This is an issue with wolfssl in openwrt. It isn't something that can be fixed in lighttpd. There are some additional choice words in my comment in https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/src/mod_wolfssl.c#L2036 At the time -- and I believe this is still the case -- wolfssl built without |
While that might work for stunnel, that does not necessarily help lighttpd using libwolfssl. Unfortunately, wolfssl is very, very, very, very, very messy with preprocessor defines that are over-used, inconsistently used, poorly named, and poorly designed (poorly levelized; poor API interface). Adding An example of the wolfssl design failures: HAVE_OPENSSLALL should be a feature set, which enables HAVE_SNI and other things. HAVE_OPENSSLALL should not be all over the code. Rather, the HAVE_SNI and other features it enabled should be in the code. Same goes for HAVE_STUNNEL, which should be a feature set which enables a set of HAVE_<feature>. Instead, HAVE_OPENSSLALL and HAVE_STUNNEL (and many others) are littered inconsistently throughout the code. Here's some preprocessor defines in wolfssl v4.5.0 wrapping struct members, function definitions, and calls to those functions.
The next version of wolfssl (not yet released) does add HAVE_LIGHTY to more places, and I'll update lighttpd mod_wolfssl.c to check for that wolfssl version once it is released. In the meantime, would openwrt developers suggest that I modify lighttpd code to check for HAVE_STUNNEL? I could do that in a patch for openwrt lighttpd build, but I do not want to add a "wolfssl-stunnel-specific" define into lighttpd code, as it really doesn't belong in lighttpd code. @cotequeiroz would you consider adding |
I was just looking for the SNI functions at the current wolfssl binaries with
Reading you latest explanations, it may not be an indication that it will actually work. I'll try to see how much larger the library is going to be with the suggested options. |
From a quick look, I think that SNI will work in the current build, due to As for silent failures, I don't have an example this second, but I seem to recall frustration with other TLS features not working with lighttpd mod_wolfssl until I enabled |
FYI: one example of silent failure with client certificate verification in lighttpd mod_wolfssl: in wolfssl |
Bug in wolfssl:
and if
|
I submitted a pull request to wolfssl (wolfSSL/wolfssl#3538) to put all SNI-related code behind HAVE_SNI instead of the more complex (and inconsistent) set of preprocessor directives currently used. For openwrt, what do you recommend for lighttpd mod_wolfssl and SNI? For openwrt, should I submit a patch which checks for HAVE_STUNNEL? Separately, client certificate validation in lighttpd mod_wolfssl will not be an available feature with current openwrt build of wolfssl unless the openwrt build of wolfssl chooses to build with |
I've just tried the suggested options. The size increase is not dramatic:
@flyn-org
What's the intent here? |
@cotequeiroz the intent of that Makefile snippet is to ensure that at least one TLS module is selected if CONFIG_LIGHTTPD_SSL is enabled. Since mod_openssl was previously the only option, mod_openssl is the one selected for compatibility. |
A failproof way to do this is by adding some symbols to
The same logic could be applied to |
Thanks for those pointers @cotequeiroz I'll do some experiments for a future update. I traced my development and found the reason why lighttpd mod_wolfssl is coded to require OPENSSL_ALL for SNI. If wolfssl is built To be practical, I'll consider having lighttpd mod_wolfssl check for HAVE_STUNNEL, even though it is messy. I am sorry that so many people (including me) have wasted time on this. Hopefully, the wolfssl team will get the message in wolfSSL/wolfssl#3538 |
I've just sent a patch series to the openwrt mailing list, enabling both |
Thanks @cotequeiroz For my part, I filed #14153 with a patch for lighttpd mod_wolfssl SNI detection, and I'll include the patch in the next official lighttpd release. FYI: this is the problematic code (similar in three places in wolfssl) in the current v4.5.0 release of wolfssl. Notice that neither HAVE_SNI or HAVE_LIGHTY are present. Without the preprocessor logic below, the SNI callbacks are not executed in wolfssl.
|
add complex preproc logic for SNI detection - HAVE_SNI is not sufficient - HAVE_LIGHTY is not sufficient (in wolfssl <= 4.5.0) Instead, use more complex logic wrapping calls to SNI_Callback() in wolfssl. x-ref: "[lighttpd] -mod-wolfssl inhibited by missing library functionality" openwrt/packages#14142 "put all SNI code behind simpler preprocessor directive HAVE_SNI" wolfSSL/wolfssl#3538
The wolfssl changes I proposed were accepted: openwrt/openwrt@f31c9cd and openwrt/openwrt@4e8a001 @n8v8R, or anyone, can you test to see if it works now? |
incorporate suggestion from cotequeiroz (Eneas U de Queiroz) openwrt#14142 (comment) Signed-off-by: Glenn Strauss <gstrauss@gluelogic.com>
Thanks, @cotequeiroz |
I can confirm that SNI is working now for lighttpd with mod_wolfssl. Tested with lighttpd 1.4.59 and wolfssl 4.6.0 on
(Sorry for the delay in getting back to this) |
lighttpd:1.4.56-3
lighttpd-mod-wolfssl: 1.4.56-3
Maintainer: @flyn-org
Tag: @gstrauss
libwolfssl24: 4.5.0-stable-2
Maintainer: @cotequeiroz
Environment: mvebu/cortexa9
#14139 (comment)
The text was updated successfully, but these errors were encountered: