martes, 11 de marzo de 2008

Utilizando stunnel para dar soporte SSL a KNode

Rescatando a brain_back-up del abandono, hoy vamos a ver como hacer para que el lector de noticias KNode de KDE3 pueda conectarse a servidores configurados para utilizar conexiones SSL. Esta opción está presente en muchos otros lectores de noticias, pero no ha aparecido en KNode sino hasta la versión proporcionada con KDE4.

La necesidad de SSL frente a conexiones TCP normales surge para evitar que la información de autorización (para los servidores que la requieren) viaje sin encriptar a través de internet. La herramienta auxiliar que vamos a utilizar es stunnel, que nos va a permitir crear un túnel SSL entre nuestra máquina y el servidor remoto.

La idea es poner a stunnel a escuchar conexiones en un PUERTO_LOCAL de nuestra PC para hacer que las encripte y redirija hacia un HOST_REMOTO y un PUERTO_REMOTO. Al correr KNode, vamos configurarlo de modo que en lugar de conectarse al servidor remoto, se conecte a localhost:PUERTO_LOCAL.

Para establecer el túnel, llamamos:

sudo stunnel -c -d PUERTO_LOCAL -r HOST_REMOTO:PUERTO_REMOTO -f



La opción -c indica que es el servidor remoto el que pretende utilizar SSL. La opción -f evita que stunnel libere la terminal y ejecute como demonio, con el fin de desplegar la información de log en pantalla y poder cerrar el túnel con un simple Ctrl + C.

Tras hacer esto, vamos a ver una salida como la siguiente indicando que el túnel se creó con éxito:

2008.03.11 11:33:25 LOG5[9199:3082761904]: Using 'HOST_REMOTO.PUERTO_REMOTO' as tcpwrapper service name
2008.03.11 11:33:25 LOG5[9199:3082761904]: stunnel 3.26 on i486-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.8e 23 Feb 2007
2008.03.11 11:33:25 LOG5[9199:3082761904]: FD_SETSIZE=1024, file ulimit=1024 -> 500 clients allowed



Luego abrimos KNode y vemos como ahora puede conectarse sin problemas.

Hacer esto cada vez que queremos leer noticias puede ser medio tedioso, por lo que podemos por ejemplo utilizar un script para que cree el túnel, ejecute KNode y luego lo destruya al terminar. Para esto puede ser útil utilizar sudoers, para evitar tener que introducir el password cada vez que queremos iniciar KNode.
Otra opción es iniciar el túnel como un servicio, agregando un script a /etc/init.d para que abra el túnel cuando se inicia el sistema y lo cierre al finalizar.
La última y más eficiente es configurar xinetd para que escuche el PUERTO_LOCAL y al recibir una conexión entrante forkee un stunnel para que la atienda. De esta manera cuando la conexión es finalizada, stunnel termina e xinetd vuelve a escuchar el puerto.

Esto ya queda medio obsoleto con la nueva versión de KNode de KDE4, pero es bueno saber que existe y entender como funciona por si lo volvemos a necesitar en otro caso. Saludos!

2 comentarios:

david santos dijo...

Buen trabajo.
Es siempre bueno para nosotros saber que pasa en otros países.
Gracias.

neoAKiRAz dijo...

Bueno, estrenaste los comentarios en mi blog... Gracias! Solo que la verdad que no se de que hablas... :) A menos que te refieras a que en Uruguay también 'pasa' Linux... Saludos!