Config for lighttpd only for mod_openssl?

[janbrasna]

Instructions hint at picking one TLS module, won't mod_openssl and mod_gnutls options (and values!) differ? So rather than a choice of mods the note should say there are other mods but this only configs openssl?

[gstrauss]

Your questions are already answered in the official lighttpd documentation. https://wiki.lighttpd.net/Docs_SSL

won't mod_openssl and mod_gnutls options (and values!) differ?

No, except for the cipher list, and you should use lighttpd TLS defaults unless you know what you're doing.
(and mozilla ssl-config-generator maintainers are waaaaaaaay behind on keeping up to date;
mozilla#189 was filed a year ago.)

So rather than a choice of mods the note should say there are other mods but this only configs openssl?

No. See above.

[janbrasna]

@gstrauss Thanks Glenn, I haven't even started comparing the docs/configs between the modules how much compatibility there is, say for ("Options" => "-SessionTicket") etc., I'll look into it eventually, to make sure the comments in the conf are not misleading.

"won't mod_openssl and mod_gnutls options (and values!) differ?"

"No,"

Well, just from quick skimming, this doesn't really "answer my questions":

"For TLS module alternatives to openssl, many ssl.* options are mapped from openssl to equivalents in other TLS libraries, including ssl.openssl.ssl-conf-cmd, but not completely so, and there is no plan to fully reimplement openssl SSL_CONF_cmd() (ssl.openssl.ssl-conf-cmd)."

Too much "many", "but not completely" for my liking to base any recommendations based on this, will investigate further if there are mentions for individual features differing in support between modules. But generally that's good news, it didn't occur to me the ssl.openssl.ssl-conf-cmd would get mapped in mod_gnutls at all, so gotcha, the config is just one 👊

"won't mod_openssl and mod_gnutls options (and values!) differ?"

", except for the cipher list"

That's the main reason I started investigating this issue. Currently the tool can't generate more than one naming system for any given config, and to support gnutls names without major effort the template would have to be duplicated, listing "lighttpd+openssl" and "lighttpd+gnutls" as two distinct configs (the correct array key is mapped to output at server config level), meaning maintaining two almost identical partials:/ I can imagine extending the configs schema to support servers with multiple cipher name sets (exim is the same) and providing a dropdown in place of OpenSSL label to be able to change to GnuTLS for example, but I don't realistically see that much effort going into this; some monkey patching lighttpd.hbs#gnutls to enable two configs reading one template seems more realistic…

"So rather than a choice of mods the note should say there are other mods but this only configs openssl?"

"No. See above."

So yes, the output with mod_openssl names can't be just used for mod_gnutls, that's what I'd like to improve. TBD if that's by wording, parallel configs or some easy hacking…

"you should use lighttpd TLS defaults unless you know what you're doing"

Oh of course I would, they're great! Be it HIGH or the new 2023 default, good job!

(But this tool generates another set, from @mozilla/server-side-tls JSONs, so I focus on fixing those renders. One day I might compare that to lighty's defaults out of curiosity, but everyone's standards differ… IBM, Google, Amazon, all have policies similar, but different, so here I'm trying to generate configs being as close as possible to what @mozilla's infosec put together — these decisions have been made, and I'm not the one to change them.)

[gstrauss]

I hope that you will take some of your questions to mozilla's infosec team, including your opinions.

Regarding your research, you can review the lighttpd code for mod_openssl, mod_gnutls, mod_mbedtls, mod_nss, and mod_wolfssl. Since I am the lighttpd developer who wrote all the current code for these modules, you might save yourself some time by tentatively believing what I have said and using that as a starting point in your research.

As I documented in https://wiki.lighttpd.net/Docs_SSL, users should use the lighttpd TLS defaults unless the users really know what they are doing. Similarly, that extends to ssl-config-generator. The 'Old' specs should probably have an annoying blink tag recommending that all those who choose to use the 'Old' spec should validate the choice with their company infosec team, if applicable. The ssl-config-generator already (properly) labels 'Old' with "Compatible with a number of very old clients, and should be used only as a last resort". As such, I do not understand why you think monkey patching lighttpd.hbs#gnutls is reasonable when the proper solution is to use the lighttpd TLS defaults. Why are you wasting time on 'Old'? If someone needs to use 'Old', they either know what they are doing and do not need ssl-config-generator, or they do not know (enough) about what they are doing in this area, and are very likely using openssl instead of any alternative TLS library, so the utility of supporting gnutls priority list of ciphers for 'Old' is not terribly useful for the lighttpd use case, IMO.