On Tue, Jun 1, 2010 at 7:09 AM, Michal Trojnara Michal.Trojnara@mirt.netwrote:

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

On Thu, Jun 3, 2010 at 5:53 PM, Jason Haar Jason.Haar@trimble.co.nz wrote:

On 06/02/2010 06:28 AM, Tristan Schmelcher wrote:

...

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.

Those sounds like design mistakes - not stunnel's to fix. We are also big users of certs and also have the issue that people involved in implementation may not (ie don't) understand the whys and hows of PKI. So:

1. make a CA that expires in 2036 (ie infinite future to all intents and

purposes) 2. make all server certs expire in 2035 (ie they won't expire) 3. ensure your CA pubkey is installed into every app or device that needs it (Active Directory was great for Windows) 4. ensure everything is set up to support revocation (I just gotta say that)

Doesn't that fix the problem you are trying to solve? The device won't need to download the certs from the other end, as they are signed by the CA they already trust. They also effectively never expire - so that entire issue doesn't need to be managed. We have VPN routers untouched in nearly 10 years doing this sort of thing. In fact, it's so low maintenance, people are forgetting how we did it in the first place - but that's s different problem ;-)

We do all four of the things you list above, but that isn't sufficient to secure the system. Suppose that a malicious party were to purchase a server from us under the guise of being a legitimate ISP. They could then extract the certificate and private key from it and copy them to a server of their own design. They then could place that device in the physical network path between one of our embedded devices and servers in use by a real ISP and spoof the IP of the real server. Since their certificate is already signed by us, the client will accept it, and since we do not know that this device is in the hands of a criminal there is no way to add the certificate to a CRL beforehand. So this malicious server will get the full trust of the client. Going one step further, this attacker could also purchase a client device from us and extract its cert and key to be able to launch a complete man-in-the-middle attack and listen in on all data without either the client or server detecting that anything is wrong.

This is the attack that we use CN/DNS verification to protect against. There is no way to protect against it any other way, because using verify = 3 is not possible with this system.

Also your point about "verify = 3" being susceptible to MITM is solved of course by "verify = 2".

-- Cheers

Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

---

stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users

On Thu, Jun 3, 2010 at 9:07 PM, Jason Haar Jason.Haar@trimble.co.nz wrote:

On 06/04/2010 03:29 PM, Tristan Schmelcher wrote:

...

We do all four of the things you list above, but that isn't sufficient to secure the system. Suppose that a malicious party were to purchase a server from us under the guise of being a legitimate ISP. They could then extract the certificate and private key from it and copy them to a server of their own design. They then could place that device in the physical network path between one of our embedded devices and servers in use by a real ISP and spoof the IP of the real server. Since their certificate is already signed by us, the client will accept it, and since we do not know that this device is in the hands of a criminal there is no way to add the certificate to a CRL beforehand. So this malicious server will get the full trust of the client. Going one step further, this attacker could also purchase a client device from us and extract its cert and key to be able to launch a complete man-in-the-middle attack and listen in on all data without either the client or server detecting that anything is wrong.

This is the attack that we use CN/DNS verification to protect against. There is no way to protect against it any other way, because using verify = 3 is not possible with this system.

If they are doing all that - they would have already fiddled with DNS...

As I described earlier, our DNS infrastructure is not vulnerable to traditional a man-in-the-middle attack. Even for other systems where it is possible, it still provides an additional layer that an attacker must compromise in order to be successful.

IMHO I think you're over-engineering this. If that is the enemy you *have to* design against, then you shouldn't be using SSL - you should get yourselves a bunch of cryptologists and invent your own proprietary alternative like DRM products do - security-through-obscurity is probably your best friend... However if the bad guys have your equipment, then they can reverse engineer that too.

I don't think this should qualify as over-engineering when DNS verification is trivial to do.

The attack you are describing affects every bank in the world running HTTPS - and governments are suspected of carrying out these very attacks. I don't see banks scurrying around trying to solve it - I think it's in the "too hard and I might get killed" basket.

We have customers that require this level of security.

-- Cheers

Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

---

stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users

Jason Haar wrote:

IMHO I think you're over-engineering this. If that is the enemy you *have to* design against, then you shouldn't be using SSL - you should get yourselves a bunch of cryptologists and invent your own proprietary alternative like DRM products do - security-through-obscurity is probably your best friend... However if the bad guys have your equipment, then they can reverse engineer that too.

In my humble opinion as a cryptologist (http://ehash.iaik.tugraz.at/wiki/StreamHash) and a penetration tester (http://www.linkedin.com/in/mtrojnar) security-through-obscurity is your worst enemy. It is also *my* best friend, since I make a living by breaking proprietary cryptographic protocols. 8-)

Mike