(not (yet?) an end-user option in the build system)
(If extended to build system, build system should also unset CRYPTO_LIB)
If WITHOUT_LIB_CRYPTO is defined in sys-crypto.h, then non-TLS modules
will have access to MD5() and SHA1() built with lighttpd (algo_md5.[ch]
and algo_sha1.[ch]), but not to other message digest algorithms.
As of this commit, this affects only mod_secdownload with SHA256 digest
and mod_auth* modules using HTTP Digest Auth with digest=SHA-256, which
is not currently well-supported by client browers (besides Opera)
use NSS crypto if no other crypto avail, but NSS crypto is available
"NSS crypto support" is not included in tests/LightyTest.pm:has_crypto()
due to NSS libraries (freebl3) lacking public export for HMAC funcs
Prefer some WolfSSL native APIs when building with WolfSSL.
However, some functionality in WolfSSL is available only through the
WolfSSL compatibility layer for OpenSSL, so the effort to create a
native mod_wolfssl halted here.
(experimental)
mod_gnutls supports most ssl.* config options supported by mod_openssl
x-ref:
"GnuTLS support for the mod_ssl"
https://redmine.lighttpd.net/issues/109
(experimental)
mod_mbedtls supports most ssl.* config options supported by mod_openssl
thx Ward Willats for the initial discussion and attempt in the comments
https://redmine.lighttpd.net/boards/3/topics/7029
./configure --with-nettle to use Nettle crypto lib for algorithms,
instead of OpenSSL or wolfSSL. Note: Nettle does not provide TLS.
x-ref:
"How to use SHA-256 without OpenSSL?"
https://redmine.lighttpd.net/boards/2/topics/8903
RAND_cleanup is deprecated and does nothing with 1.1.x.
It also breaks with OpenSSL compiled with no deprecated APIs.
(-DOPENSSL_API_COMPAT=<version>)
github: closes #93
defer li_rand_init() until first use of li_rand_pseudo_bytes()
li_rand_init() is now deferred until first use so that installations
that do not use modules which use these routines do need to potentially
block at startup. Current use by core lighttpd modules is in mod_auth
HTTP Digest auth and in mod_usertrack. Deferring collection of random
data until first use may allow sufficient entropy to be collected by
kernel before first use, helping reduce or avoid situations in
low-entropy-generating embedded devices which might otherwise block
lighttpd for minutes at device startup. Further discussion in
https://redmine.lighttpd.net/boards/2/topics/6981
prefer RAND_pseudo_bytes() (openssl), arc4random() or jrand48(),
if available, over rand()
These are not necessarily cryptographically secure, but should be better
than rand()
Glenn Strauss
Rosen Penev