[stunnel-users] Three patches

[Michal Trojnara]

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