Utilización de stunnel

En el momento de escribir esto, la última versión de stunnel es la 3.8p4, que es muy aconsejable porque permite, entre otras cosas, un mayor control sobre la ubicación de certificados. Se puede conseguir en http://www.stunnel.org.

stunnel es un programa muy útil que nos permite utilizar conexiones SSL con clientes y/o servidores que no soportan este protocolo. Algunos ejemplos de uso son:

Utilizar el modo de conexión SSL entre un cliente que tenga esa opción y un servidor POP o IMAP que no.
Lo mismo pero al revés (el servidor soporte SSL y el cliente no).
Encriptar cualquier conexión TCP entre dos ordenadores, permitiendo opcionalmente el control de acceso al servidor desde determinados clientes.

stunnel debe ejecutarse en el extremo de la conexión donde se quiera tener la funcionalidad SSL que de otra forma no se tiene. Así, en el primero de los ejemplos anteriores, habría que ejecutarlo en el servidor POP/IMAP. En el caso de IMAP la orden sería:

stunnel -d 993 -r 143

La opción -d indica en qué puerto debe escuchar. En este caso, puesto que hemos supuesto que el cliente soporta IMAP sobre SSL, el puerto debe ser 993, que es el asignado para ello (imaps). La opción -r indica a qué host y puerto debe redirigir la conexión (ésta última ya no es SSL). Si no se indica host se conecta a sí mismo. En este ejemplo es el puerto habitual de IMAP.

Otra forma de hacerlo es:

stunnel -d 993 -l /usr/sbin/imapd -- imapd

En este caso no redirige la conexión al puerto estandar de IMAP, sino que el mismo stunnel se encarga de lanzar el servidor, asumiendo así el mismo papel que inetd. En este caso el programa servidor debe soportar ese modo de ejecución (via inetd, no abriendo la conexión por sí mismo). Tras el doble guión se pone lo mismo que en el fichero inetd.conf tras el nombre del ejecutable.

Si el extremo de la conexión donde no tenemos un software SSL es el cliente, también podemos usar SSL. En este caso hay que ejecutar, en la máquina cliente:

stunnel -c -d 1999 -r sslserver:puerto-s

y configuramos el cliente para que se conecte a locahost al puerto 1999.

Lo importante a recordar a es que:

En modo servidor (cuando no se usa la opción -c), la conexión entrante (por el puerto dado en -d) es SSL, y la que genera stunnel (dada por -r) no lo es.
En modo cliente ocurre justo lo contrario.

Podemos también encriptar cualquier conexión en la que ni cliente ni servidor sean SSL. Por ejemplo, para encriptar la conexión IMAP entre un lector de correo de PC y un servidor:

En el cliente:
```
stunnel -c -d 143 -r servidor_imap:1999
```
Habrá que configurar el programa de correo para indicarle que el servidor IMAP es el propio PC (una de las cosas buenas de stunnel es que tiene una versión casi totalmente funcional para PC).
En el servidor:
```
stunnel -d 1999 -r localhost:143
```

Aquí también hemos cogido un puerto aleatorio (1999) para la conexión encriptada.

Este último caso es lo mismo que se puede conseguir con SSH de la forma:

ssh -L 143:servidor_imap:143 servidor_imap

La ventaja de stunnel es que no hay que tener una cuenta de la máquina remota. Debe ser el administrador de la misma (o nosotros si tenemos allí cuenta) quien arranque el servidor stunnel. No hay que indicarle a SSH un puerto aleatorio porque todo el tráfico encriptado va por la conexión que se establece con el servidor.

Certificados

Cuando stunnel funciona en modo servidor, debe presentar un certificado al cliente, como todo servidor SSL. La distribución de stunnel trae uno, pero es conveniente generar uno propio, usando OpenSSL por ejemplo. La clave privada debe residir en un fichero no encriptado para que el programa pueda acceder a ella sin tener que pedir clave. Lo mismo cabe decir si se van a usar certificados en modo cliente, para su autentificación. Esto es un problema importante de seguridad, sobre todo en el caso de un PC, donde cualquier con acceso al mismo podrá acceder a la clave privada. Estaría bien que el programa soportara tenerla encriptada y contemplara formas de acceder a la misma al arrancar, como hace mod_ssl (como pedir la frase de paso al usuario, obtenerla mediante un programa o variables de entorno, etc.).

La autentificación de cliente puede imponerse ejecutando el servidor con la opción -v, cuyo argumento indica el nivel de autentificación exigido. Los valores que puede tomar son:

1 - El cliente puede presentar o no un certificado. Si lo hace, comprobar que es válido.
2 - El cliente debe presentar un certificado, que es verficado por el servidor. Si no es válido no acepta la conexión.
3 - El cliente debe presentar un certificado, el cual debe ser figurar en una lista de certificados válidos almacenados en el servidor.

Un certificado se considera válido cuando va firmado por un CA cuyo certificado conozca el servidor (por tanto no aceptará certificados de cliente auto-firmados). Estos pueden residir uno en cada fichero o todos en el mismo. En el primer caso, los nombres de los certificados deben tener nombres del tipo XXXXXXXX.0 (generados con openssl x509 -hash), y el nombre del directorio se le pasa a stunnel con la opción -a. Para el segundo caso (todos en el mismo fichero), se usa la opción -A.

Estas opciones nos pueden servir para implementar un control de acceso, para lo cual también se puede utilizar el control de TCP Wrappers, si stunnel se compiló con soporte para ello.

Para crear los certificados podemos usar OpenSSL. En la página Creación de certificados para stunnel se muestra una forma sencilla de hacerlo.

Veamos un ejemplo completo de cómo conseguir una comunicación segura con control de acceso al puerto 25 (SMTP) de un servidor desde un PC, suponiendo que en ninguna de las máquinas tenemos software SSL, y que hemos seguido el procedimiento de la página antes mencionada para crear los certificados de servidor y de clientes:

Llevarse el fichero client.pem al PC, al directorio donde tengamos el stunnel.exe.

Ejecutar en el servidor:

stunnel -d 1999 -r 25 -p $CADIR/certs/server.pem \
        -v 3 -A $CADIR/cacert.pem -a $CADIR/certs

Ejecutar en el cliente:

stunnel -c -d 25 -r servidor:1999 -p client.pem

Configurar el cliente de correo de forma que el servidor SMTP es el propio PC.

Si en el servidor queremos aceptar cualquier cliente cuyo certificado haya sido firmado por nuestra CA, la orden a ejecutar en el servidor sería:

stunnel -d 1999 -r 25 -p $CADIR/certs/server.pem \
        -v 2 -A $CADIR/cacert.pem

Nota: En modo cliente, el fichero con el certificado debe estar accesible cuando stunnel se ejecuta, aunque éste no lo usará si no se da la opción -p. Como, si no se da esa opción, el fichero que busca por defecto es stunnel.pem, tendremos que tener ese fichero con ese nombre (a no ser que usemos otro con -p).

Formas de funcionamiento

Ya hemos visto que stunnel puede actuar como cliente o como servidor. Estos roles se refieren a conexiones SSL, porque el cliente también puede ser servidor de conexiones no-SSL (opción -d), y el servidor puede ser cliente (opción -r).

En el caso del cliente, hay tres fuentes de las que puede obtener la conexión a enviar por el canal SSL:

Opción -d (modo daemon)
Por inetd. Un ejemplo de entrada en inetd.conf es:
```
servicio stream tcp nowait root /usr/local/sbin/stunnel \
  stunnel -c -r host:puerto-s
```
En este caso no es necesario usar la opción -d porque obviamente la conexión se la da abierta inetd. Esta forma tiene el inconveniente de la lentitud por el arranque del programa en cada. conexión.
Mediante un programa externo (con -l). En este caso son la entrada/salida estandar del programa lo que se envía por la conexión SSL:
```
stunnel -c -r server:puerto-s -l /.../programa
```
Aquí en cuanto termina el programa, termina stunnel.

Lo que sí es obligatorio en el caso del cliente es la opción -r, para indicar a qué servidor y puerto SSL hay que conectarse.

En el caso del servidor, puede obtener la conexión SSL de dos fuentes:

Opción -d (modo daemon).

Por inetd, como en el caso anterior.

servicio-s stream tcp nowait root /usr/local/sbin/stunnel \
  stunnel -r host:1999

El servidor puede conectarse a un destino de dos formas:

Opción -r
A un programa externo:
```
stunnel -d puerto-s -l /.../programa
```
En este caso se conecta con las entrada/salida estandar del programa.

La opción -L es semejante a -l, pero en este caso se abre un pseudo-tty para ejecutar el programa y es el descriptor esclavo del mismo el que se conecta. Esto se usa para encriptar conexiones PPP (ver la FAQ para más detalles).

En resumen:

	Origen	Destino
Cliente (-c)	-d, -l, -L, inetd	-r
Servidor	-d, inetd	-r, -l, -L

Nota: En la versión de PC no están disponibles las opciones -l y -L.

Veamos un último ejemplo que permite enviar texto a un servidor, el cual lo va almacenando en un fichero:

En el servidor, en inetd.conf (tras definir servicio-s en el fichero /etc/services):

servicio-s stream tcp nowait root /usr/local/sbin/stunnel \ 
  stunnel -l  /bin/dd -- dd of=/tmp/salida

En el cliente:

stunnel -c -r server:servicio-s -l /bin/cat -- cat fichero

Más notas: Si ejecutamos stunnel en el modo inetd, tenemos problemas en sistemas operativos, como Solaris, que no permiten pasar a un programa arrancado de esta forma más de 5 argumentos, por lo que si hay que usar la opción -p o -R (para indicar el fichero de datos aleatorios, si es necesario), puede que tengamos que compilar el programa con esos datos por defecto, de forma que no haya que pasárselos como argumentos.

Más información:

http://www.stunnel.org
http://mike.daewoo.com.pl/computer/stunnel
http://www.ssh.com
http://www.openssh.com
http://munitions.vipul.net/0208.shtml
http://www.openssl.org
http://www.stunnel.org/faq/certs.html
http://www.rickk.com/sslwrap/ - programa semejante a stunnel

- Junio 2000