Paranoid Penguin - Rehabilitating Clear-Text Network Applications with Stunnel
A Stunnel server—that is, a host that receives encrypted packets destined for a local clear-text service—requires a server certificate. A Stunnel client does not, however, unless you intend to configure your Stunnel server to use client-certificate authentication. Sadly, client-certificate authentication is beyond the scope of this article, so none of our examples require the client to have its own certificate—only the server does.
If you installed Stunnel after compiling from source and issuing a make install command, you've already got a server certificate (/usr/local/etc/stunnel/stunnel.pem). If you installed Stunnel from a binary package, the package's post-installation script may or may not have created a server certificate for you.
Fedora Core 1's Stunnel RPM creates an empty certificate for some reason. Needless to say, you need a proper certificate, and the way to do that on Fedora is to change your working directory to /usr/share/ssl/certs, type make stunnel.pem and copy stunnel.pem to the directory /etc/stunnel. This certificate, as with certificates created by the Stunnel source-release Make script, has no passphrase.
The Danger of Passphrase-Free Certificates
Using a server certificate that's been generated automatically or semi-automatically by a script is quick and convenient, but there's one problem: such a certificate nearly always is created with no passphrase. On the one hand, you can and should set the permissions and ownership on your certificate to make it root-readable only, so at least unprivileged users on your system aren't able to read and thus use it. On the other hand, if your system is root-compromised, your passphrase-free certificate then can be used and abused by the attacker.
This may be an acceptable risk for you, and indeed, using passphrase-free server certificates is a common practice. After all, it's inconvenient to require a human being to enter a certificate's passphrase every time Stunnel starts up. However, as a matter of principle, crypto experts widely consider it reckless to use passphrase-free certificates. If a process is sensitive enough to warrant cryptography in the first place, the argument goes, it's sensitive enough to require a human being to start that process.
If your Stunnel server system needs a server certificate, or if your automatically generated certificate doesn't meet your needs—for example, it lacks a passphrase—you need to generate your own, using the OpenSSL command. Space does not permit me to give a full, proper explanation of this powerful tool. Luckily, the Stunnel FAQ (see Resources) answers some of the most common questions about how OpenSSL and Stunnel interact, and it includes pointers to further sources of information about OpenSSL.
Suffice it to say that for some users, there may be a compelling reason to create their own Certificate Authority (CA), install their CA certificate (but not key) on every system running Stunnel and use their CA certificate to sign all server certificates. This is necessary, for example, if you want your Stunnel server systems to accept client connections only from Stunnel client hosts with particular certificates.
For many if not most Stunnel users, however, it's good enough to use self-signed certificates and to not worry about being or not being a CA. Here's how to generate a self-signed server certificate using OpenSSL.
Listing 1. Creating a Server Certificate with OpenSSL
nearclient:/etc/stunnel# openssl req -x509 \ -newkey rsa:1024 -days 365 \ -keyout stunnel.pem -out stunnel.pem Using configuration from /usr/lib/ssl/openssl.cnf Generating a 1024 bit RSA private key ...++++++ .............................................++++++ writing new private key to 'key2.pem' Enter PEM pass phrase: ************ Verifying password - Enter PEM pass phrase: ****** ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) :Minnesota Locality Name (eg, city) :St. Paul Organization Name (eg, company) :Wiremonkeys Organizational Unit Name (eg, section) : Common Name (eg, YOUR name) :nearclient.wiremonkeys.org Email Address :X.email@example.com nearclient:/etc/stunnel# chmod 600 stunnel.pem
In Listing 1, the real meat is in the first line. Parsing from left to right, this command tells OpenSSL to create a certificate request in the X.509 digital certificate format, using the RSA cipher with a 1,024-bit key, good for 365 days and with both its key and (public) certificate written to the same file, stunnel.pem. If you instead want to create a password-free certificate, you can include the -nodes option at the end. Read the sidebar “The Danger of Passphrase-Free Certificates” first, though.
Most of the rest of Listing 1 shows a dialog in which OpenSSL prompts me for X.509-type information to include in the certificate, including Country and Region. That stuff should be self-explanatory, but Common Name is very important. If you're creating a server certificate, the certificate's Common Name must be set to the fully qualified domain name (that is, the full hostname) of the host that is going to use the certificate.
Most SSL/TLS-enabled applications expect this Common Name to resolve by way of DNS to the IP address of your server. Stunnel does not unless you configure it to, but setting Common Name to your FQDN is a good habit to get into nonetheless.
In the last line of Listing 1, I've set the permissions of my new server certificate to 0600 (-rw-------). Because I ran my OpenSSL command as root, this file already is owned by root. It's important for any server certificate, whether it's password-protected or not, to be root-readable only. I ran my OpenSSL command from within /etc/stunnel, so my certificate was created in place, and I didn't have to move my new certificate there by hand.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Nice article, thanks for the
8 hours 22 min ago
- I once had a better way I
14 hours 8 min ago
- Not only you I too assumed
14 hours 25 min ago
- another very interesting
16 hours 18 min ago
- Reply to comment | Linux Journal
18 hours 11 min ago
- Reply to comment | Linux Journal
1 day 1 hour ago
- Reply to comment | Linux Journal
1 day 1 hour ago
- Favorite (and easily brute-forced) pw's
1 day 3 hours ago
- Have you tried Boxen? It's a
1 day 9 hours ago
- seo services in india
1 day 13 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?