[stunnel-users] Three patches

[Tristan Schmelcher]

On Tue, Jun 1, 2010 at 7:09 AM, Michal Trojnara <Michal.Trojnara at mirt.net>wrote:

>
> 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?
>
>
Those are just the four that required Stunnel changes in order to disable.
The full set of features that I disabled in OpenSSL was:

no-ssl no-md2 no-md4 no-rc2 no-idea no-ripemd no-bf no-cast no-ec no-ecdsa
no-krb5 no-store no-dh no-engine no-mdc2 no-camellia no-seed no-cms

Which reduced the size of my statically-linked stunnel binary from about 1.5
MB to about 1.0 MB.


> > 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
>
>
Yes, but I think an option is better because it avoids dropping stderr
messages from sources other than s_log--for example, libc asserts. If all of
stderr is redirected then one might never know when such errors had
occurred.

> 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?
>

For most applications of stunnel I agree with you, DNS verification is
inherently insecure and verify = 3 is better, hence why I made this an
option that defaults to off. But for some applications verify = 3 isn't
practical, especially embedded systems.

Let's use my company's embedded device product as an example (slightly
simplified). It sits in an ISP's network and periodically connects to some
TLS servers. The servers are owned by the ISP and their host names are
private to the ISP's internal network, but they are located outside of the
ISP's physical offices (specifically, in the offices of the ISP's
customers). The number of such servers and their addresses is an option that
the operator of the device must configure. However, the operator may not
know anything about SSL/TLS or certificates, and after configuring the
device he/she will probably forget that it exists. So the device must be
designed to be as secure as possible within these constraints.

If we used verify = 3, we would first of all need the operator to download
and save those remote certificates to the device. An app would help, of
course, but simply the existence of this step would already present a
significant barrier to configuring the device. (For example, the operator
may not understand why such a step is needed, or may not know where to find
the application--especially if it has been a long time since the ISP
purchased the device.) A bigger issue though is that the server's
certificates could be changed at a later date without the operator's
knowledge--for example, because they have expired. Using verify = 3, we
would no longer be able to connect to that server. Since this is an embedded
device with no monitor and no normal "user", there is nobody to report the
error to. Even if we did find a way to get someone to realize that there is
an issue, it is not very likely that the operator who originally configured
the device is still around, or that they remember anything about it. So
instead we use verify = 2 and verify_dns = yes. DNS queries are answered by
the ISP's own DNS servers, so the risk of a DNS spoofing or cache poisoning
attack is fairly low.

Ours is a somewhat unique case of course because DNS is much more "secure"
for us than it is in most other cases, but I think verify_dns still offers
(marginally) increased security for some people. Even if using verify = 3,
it could still be beneficial to add verify_dns = yes, because the one-time
process of manually downloading the certificates is vulnerable to a trivial
man-in-the-middle attack if an attacker knows the approximate time that it
will happen and has their own certificate ready to switch with the real one.
If verify_dns = yes is added, the attacker has to _also_ launch a successful
DNS attack in order to compromise the system. Depending on their skill and
degree of access to the network that may be trivial, but it also may not be.

Another case where it would be helpful is when stunnel is being used from a
script that generates a config file dynamically (e.g., with the stunnel3
wrapper) and hence the set of possible servers to connect to may not be
known beforehand (so verify = 3 cannot be used). In this way stunnel may
actually be being used with the exact same access patterns of a web browser
by serving as an SSL tunnel for an HTTP-only browser (I have used it in a
similar way in the past). Again, DNS verification will not help against all
attacks in this situation, but it will help against some.


>
> Best regards,
>    Mike
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at mirt.net
> http://stunnel.mirt.net/mailman/listinfo/stunnel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20100601/0c3334ce/attachment.html>