Stunnel: Home
 |
Stunnel: Home | Upgrade 4.24 | Install | SSL Certificate | Single Vhost | Resolved | Basics | Cost | Original |
|
Stunnel Introduction |
Stunnel hardware point of view
Stunnel is described as a tunnel or wrapper this terminology I find difficult to understand, fine if you are a software engineer I personally like to visualise certain software as physical objects. Stunnel is a server in its own right dedicated to providing encryption and decryption it is best viewed as a four terminal device.
Stunnel Block Diagram
This block diagram explains how I view Stunnel. It removes the myriad of abstract software layers. Stunnel has two basic configurations either server or client this block diagram shows a server configuration.
|
It is a four terminal component with two input (1,3) and two output (2,4) terminals. Has five distinct blocks, connect 1 and connect 2 providing connections to either the outside world or locally. Two blocks provide encryption and decryption. The final block links the above four together providing switching control and signal routing as appropriate. This control block is configurable via a configuration file. Runs in either of two modes, server or client. Note 1: Each terminal is associated with a port number. Connect and Accept ports are defined in the configuration file, The other ports connect to terminals 3 and 4 these ports are created during connection. |
|
It looks deceptively simple and I do admit, hides a very elegant and cleaver piece of software.
In this write up I explain Stunnel’s basic operation for securing Apache. After reading this step-by-step guide I hope it will make Stunnel easier for you to deploy.
Extra terminals
Uniform Server uses Stunnel configured in server mode, terminal 1 connects to the Internet, which ultimately connects to a users browser, and terminal 2 connects to Apache.
I like to think of ports as wires, terminal 1 has a fixed wire (port) attached to it, this is port 443 which Stunnel uses to listens for incoming secure requests from a browser. Stunnel will acknowledge any request-using terminal 4 however it needs to know what wire the browser is connected to in order to send a reply (data). A browser provides this information, before making a request checks its pool of free wires (ports) and selects one, this is sent along with the request to Stunnel. This wire (port) is attached to terminal 4 by Stunnel and becomes fixed until either Stunnel or the browser breaks the connection.
Apache being a server also has a fixed listening port (80) when Stunnel communicates with Apache it is acting similar to a browser. In Stunnel's configuration file terminal 2 (connect) is hardwired to port 80. Stunnel before making a request to Apache checks its pool of free wires (ports) selects one and attaches it to terminal 3. This port number is sent along with the request to Apache where it becomes fixed until either Apache or Stunnel breaks the connection.
With the connections established, data transfer can take place. To use Stunnel all we are concerned with are the wires (ports) that need to be assigned to connect and accept, what gets connected to terminals 3 and 4 is automatic and we can forget about them.
Note: The wires and terminals are deeply buried in protocols and other technical stuff, they do no exists, just merely a way to visualise what is going on.
Con Artist
Where’s the con? Take two users one expecting a standard data channel and the other a secure one. These two users cannot communicate because their connections are incompatible. Now slip a Stunnel component between them and communication is established.
In reality both users are talking to the Stunnel but appear to be communicating directly with each other. Stunnel has conned each user into thinking they are connected to the type of channel they were expecting.
To get a feel for this interaction assume Stunnel is installed on user B’s machine and configured for server mode. Steps 1 to 8 provides an overview of the sequence that takes place to establish a secure connection.
| Unencrypted Data user B | Stunnel | Encrypted Data User A |
|---|---|---|
|
|
|
Chats with A
When Stunnel chats with user A (step 2) it passes a signed certificate and a public key to set up the secure connection. User “A” will attempt to verify the certificate with the signing authority. This certificate is either verified or in the case of a self-signed certificate accepted by the user, once this takes place a secure link is established. Further communication between user “A” and Stunnel takes place with encrypted data.
Encryption Decryption
Both Uniform Server and Stunnel are similar in design concept in that they both pull together well-proven components and integrate them in an innovative and unique way. Stunnel integrates OpenSSL which intern uses the SSLeay libarary developed by Eric A. Young and Tim J. Hudson. I forgot to mention these projects are a worldwide collaborative effort producing some extremely robust software. As an end user I get nice complied components that I can easily use, these two libraries ibeay32.dll and libssl32.dll are the heart of the encryption and decryption blocks. OpenSSL provides tools to use these libraries and generate certificates; Stunnel integrates them into a practical application.
My reason for mentioning the above, when you generate your certificates spare a thought for these guys for making it so easy.
Self-signed certificate
You have a choice of using either a self-signed certificate for personal use or one signed by a recognised authority. Check out this page for some background information. I have provided a rough guide as to what a recognised authority will charge you for a signed certificate and the irritation (inconvenience) of a self-signed certificate.
I am only going too cover self-signed certificates if you do need to use a recognised signing authority search the Internet and do some research, find one that suits your requirements, price alone is not a good comparison.
Summary
The above was written from a practical point of view. Stunnel is a two-port translator with encryption and decryption. In reality there are four ports involved in the communication process, two of these are normally taken for granted hence never explained.
The remainder of this document covers my Stunnel plugin modified for Uniform Server 3.5-Apollo, when the official plugin is released I hope to cover that.
| |
Ric |