On Tue, Jun 1, 2010 at 7:09 AM, Michal Trojnara
<Michal.Trojnara@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@mirt.net
http://stunnel.mirt.net/mailman/listinfo/stunnel-users