Tristan Schmelcher wrote:
stunnel-4.33-handle-minimal-ssl-libs.patch:
Add support for building against a libssl/libcrypo that has had various non-essential features removed via the "no-<feature>" Configure options for openssl. This requires disabling non-essential Stunnel features at compile-time if they have dependencies on disabled libssl/libcrypto features.
For memory-constrained embedded systems, this is a big win. With this patch I was able to cut the memory footprint of stunnel+openssl by about a third simply by disabling openssl features that I didn't need.
Can you share the results of your tests? How much of the binary size does disabling MD4/SSLv3/SSLv2 really save?
stunnel-4.33-separate-stderr-option.patch
This splits the stderr logging effect of the "foreground" option into a separate option named "stderr", so that users have the freedom to enable foreground without stderr logging, or vice versa. For backwards compatibility though, specifying foreground = yes implies stderr = yes unless followed in the config by stderr = no.
This is useful on embedded Linux systems that lack an implementation of fork() (due to the processor not having an MMU), because on such systems every daemon has to be launched in a foreground mode and pre-daemonized with the simpler vfork() function, e.g. using "&" from a shell. In this mode, logging to stderr does not make sense, because in reality the process is still a daemon so the logging clutters the terminal.
stunnel-4.33-dns-commonname-verify-support.patch:
Couldn't you simply redirect stderr to a file? stunnel 2>/var/log/stunnel.log
I saved the best for last. ;) This adds a "verify_dns" option to check the CommonName in peer certificates against their DNS name when verifying, much as web browsers do.
I have seen posts from users asking for this feature in the past, so I think it's value is self-evident.
The basic purpose of SSL/TLS is to prevent network-level attacks. Many years ago I refused to implement this option as it's inherently vulnerable to DNS spoofing and cache poisoning. I think my point stands even more nowadays with DNS cache poisoning attacks getting more and more popular.
Also stunnel, unlike web browsers, connects a predefined (static) list of servers. It's much more secure to just download their certificates and check them with "verify = 3".
I think I could add a Windows GUI option to download and save remote certificates. What do you think?
Best regards, Mike