Examples of encrypting existing services

Lets say you want to protect the IMAP service, which runs on port 143. Normally (ie without any SSL) you'd simply have a line like the following in /etc/inetd.conf:

	imap stream tcp nowait root   /usr/sbin/tcpd imapd

However we wish to wrap it in SSL with stunnel. Let's give two examples.

Example 1: stunnel forwards traffic (after SSL decryption) to the existing imap service (port 143).
Start up stunnel as follows:
```
	stunnel -d imaps -r localhost:imap
	
```
which says 'listen on port imaps, and forward all traffic, after decryption, to port imap (143) on localhost'. Now if we're using tcp wrappers, we probably want to do two things:
- If we want to force everyone to use the secure imaps, deny access to all machines other than localhost (127.0.0.1) to imap in /etc/hosts.allow.
- If we want to limit access to this imaps port, restrict it in /etc/hosts.allow. Note that the service name, given the way we started stunnel above, would be localhost.imap.
Example 2: stunnel launches the imapd program itself, rather than just forwarding packets to the existing imap port.
Start stunnel this way:
```
	stunnel -d imaps -l /usr/sbin/imapd
	
```
which says 'listen on port imaps, and launch the program /usr/sbin/imapd and send it the unencrypted data from the remote end.'
Again, if we want to restrict access, we'll probably do two things:
- If we don't need anyone using the imap service without SSL, simply remove the existing imap line in /etc/inetd.conf and send inetd a SIGHUP.
- If we want to limit access to this imaps port, restrict it in /etc/hosts.allow. Note that the service name, given the way we started stunnel above, would be imapd.

One important thing to remember is that you must have your client configured to use SSL. If it isn't, then it will never attempt to use the stunnel wrapper you've put in place. Make sure that your client has SSL support. If it doesn't, you will get errors noticable from the stunnel debugging output.