stunnel exercise
Installing stunnel
stunnel is probably on your system. If not, use yum to install it.
A client-server interaction (no stunnel)
stunnel tunnels a TCP conversation. So we need to have one. That means we need a client and matching server, preferably on separate machines. So work with a partner. Decide which of the 2 roles each of you will take. At the server check whether apache is running:
service httpd status
and run it if not:
service httpd start
Apache by default will serve up the file /var/www/httpd/html/index.html. Check whether it exists:
ls /var/www/html/index.html
and if so, rename it to get it out of the way:
mv /var/www/html/index.html /var/www/html/index.html.org
Use an editor to create a replacement file-- same name, same directory-- having these new contents:
<H1>This is the server.</H1> (this, on the server)
Or something distinctive; add your name if you like. Now at the client bring up a browser and point it to your server-partner's machine by entering the following URL:
http://<server's IP address> (this, on the client)
Make sure the newly created default page appears. There's nothing special here. If the traffic between your 2 machines were encrypted, however, now that would be special!
Putting stunnel between client and server
Currently the browser is talking to apache using port 80 on the latter's machine. The changes we wish to make are three:
1) disconnect the browser from apache, have him talk to stunnel on his own
machine instead,
2) disconnect apache from the browser, have him hear from stunnel on his own
machine instead, and
3) put these 2 stunnel's in place, one on each machine, and make them talk to each
other.
We want to preserve the association of apache with port 80. By contrast, we don't care what ports the other 2 conversations utilize. So let the browser reach the client copy of stunnel using that machine's port 2000, and let the client copy of stunnel reach the server copy using the server machine's port 30000. To do that, use editors to create stunnel configuration files on each computer. On the client, create the file /etc/stunnel/stunnel-client.conf with the following content:
client=yes
[speak to web server]
accept = 127.0.0.1:2000
connect = 192.168.3.12:30000 (replace
"192.168.3.12" with the actual address of the server)
On the server similarly name it /etc/stunnel/stunnel-server.conf; here's the content:
cert = /etc/stunnel/stunnel.pem
[hear web browser]
accept = 30000
connect = 80
The server copy of stunnel needs a certificate for this to work, and we can create one. Do the following on the server:
cd /etc/stunnel
openssl req -new -x509 -days 3650 -nodes -out stunnel.pem -keyout stunnel.pem
(accept all the defaults)
Finally, run the 2 copies of stunnel giving their respective config files on the command lines. On the client:
stunnel /etc/stunnel/stunnel-client.conf
And on the server:
stunnel /etc/stunnel/stunnel-server.conf
Nothing happened. But stunnels are running on both boxes, willing to listen to the browser and talk to the server (respectively). Check for stunnel listening on the clien'ts port 2000 and on the server's 30000 by running this command on both:
netstat -pant
netstat -pant
It lists the various ports being listened to and tells what program is listening. Yours should be among them.
Using the stunnels
At the client bring up the browser again. But this time, point it to its own machine and also specify the port to talk to. That port is 2000. The URL for the browser is:
http://127.0.0.1:2000 (this, on the client; 127.0.0.1 is the standard "self-reference" address in IP)
You should see the server's default web page appear. Now, however, the traffic is passing between the pair of stunnels imposed between browser and server. And they are encrypting it. Verify the conversation's dependency on this arrangement by killing one of the stunnels:
killall stunnel
then trying to refresh the browser. It won't. It's cut off from stunnel so the traffic route is disrupted..
You can still get the web page by going back to direct contact with the server, but there's no encryption. You could verify that if you like. Just browse both ways, capturing the sessions (tcpdump or wireshark) and comparing the traffic. You'll find the one contains legible HTML while the other does not. If you wished to confine apache access to the stunnel channel, you could make firewall arrangements to block port 80 and permit port 30000.