Paranoid Penguin - Rehabilitating Clear-Text Network Applications with Stunnel

Put modern crypto onto your legacy applications without modifying them. Mick Bauer shows how to bring pre-SSL programs up to date.

As you can see, a service definition can be as simple as a pair of lines, an accept line to designate a listening port and a connect line to designate a destination port. Precisely what this means depends on whether a given system is a Stunnel client or a Stunnel server. On a client system, client = yes, Stunnel expects clear-text packets on its accept port and sends encrypted packets to the connect port. On a server system, client = no, Stunnel listens for SSL connections (encrypted packets) on its accept port and sends decrypted packets to the connect port.

Also notice that on a client, in your connect statement you probably need to specify not only a port but also a remote hostname or IP address, as in Listing 3, connect =

According to the way we've configured things in Listings 3 and 4, any host can connect to TCP port 23 on nearserver and traverse nearserver's tunnel to farserver. We can restrict this in any number of ways, including by using iptables. We can tell Stunnel to accept only local connections to the Stunnel client process, however, by using accept = on nearclient.

This technique would work on farserver as well. If farserver has multiple interfaces, eth0, wlan0, ppp0 and so on, you can write your accept statement to specify the IP address of the interface on which you want it to receive tunneled packets in the same way. On both Stunnel clients and servers, the default IP for accept statements is any (all local interfaces), and the default IP for connect statements is (localhost).

What about the telnet server on farserver? After all, clear-text telnet sessions seldom are a good idea. Therefore, in practice you want to be sure to add the line bind = to your /etc/xinetd/telnet script, so that only local processes can connect to TCP 23.

Once you've finished configuring Stunnel on client and server, start Stunnel simply by typing the command stunnel. You don't need to worry about starting it on the server before starting it on the client; the client doesn't initiate a tunnel until you try to use it, for example, by trying to start a telnet session. If either or both hosts are using a password-protected server certificate, you are prompted for it now. Keep this in mind if you set up a Stunnel startup script. Once you've entered the certificate, you should be up and running.

You now can check for successful startup by issuing a quick ps auxw and looking for a Stunnel process—Stunnel returns no output to the console whether or not it starts cleanly. It does, however, send messages to your system's syslog facility, including startup messages.

Once stunnel is running on both client and server, our users on nearclient can trigger a tunnel by connecting to nearclient's TCP port 23, for example, with the command telnet (23 is telnet's default port). Listing 5 shows a sample encrypted-telnet session.

As you can see, from the end-user's perspective, connecting to farserver in this way is practically indistinguishable from any other telnet session. The bash prompt at the end of the listing, however, confirms that we have in fact connected to farserver.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Need Help On how to change port 23 to port 992

Anonymous's picture

Our network is connected to proxie server and we already set our proxie server to accept port 992 but when the client computer connects logon the the website it will be block by the proxie server so we need to change the port 23 to port 992. Pls advise if you have any detailed suggestion on how to do this. The client PC is running windows XP pro and the server is running windows server 2000

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState