logo-IRIS
  
> Inicio
> Sitemap
> Contacto
> Buscador
  



< Servicios < Correo electrónico

Grupo de Trabajo "Seguridad en el Correo Electopnico" - GTI-SMAIL

Introducción · Fase I · Fase II · Material

Servicio Correo Electrónico RedIRIS

Introduccion

A finales de 1999 se organizo el Grupo de Trabajo GT-SMAIL para estudiar y aportar soluciones acerca de los diferentes problemas se seguridad que existen en las transacciones u autenticaciones en el uso del correo-e. Este grupo de Trabajo esta coordinado por:

Borja Peres Oñate < borja@posta.unizar.es >

En el siguiente documento encontrará una panorámica general de los objetivos de este Grupo de Trabajo y una análisis de la seguridad de las transacciones de correo-e:

Seguridad en el transporte del correo-e

Fase I del GTI-SMAIL

Objetivos

Los objetivos de la Fase I del GTI-SMAIL fueron:

  • Abordar la comunicacion cifrazada entre clientes y servidores pop e imap usando el paquete stunnel.
  • Modificar un cliente WebMail (MailMan de Endymion) para utilizara SSL contra los servidores POP via stunnel.
  • Generacion de certificados para el stunnel

La idea de esta primera Fase era estudiar la problematica e investigar y evaluar soluciones y herramientas para que las transacciones smtp (servidor-servidor y cliente-servidor) y pop/imap (cliente-servidor) tuvieran una nivel de seguridad suficiente para evitar ataques pasivos producidos cuando alguna aplicacion escucha el trafico de la red accediendo al contenido de los mensajes y a los datos de acceso: login y clave.

El material utilizado ha sido:

  • stunnelque incorpora la funcionalidad SSL(TLS) en los servidores POP/IMAP. Este paquete crea un canal seguro entre cliente y servidor.

  • MailMan de Endymion Este es un cliente WebMail que modificado nos permitiria hacer pruebas contra servidores POP via Stunnel. Estas modificaciones fueron hechas por Borja Prieto y han sido incorporadas en el codigo del MailMan de RedIRIS (SAUCE). La idea es que desde este servicio los usuarios de las instituciones que tuvieran instalado stunnel/pop pudieran acceder a sus buzones de correo-e a traves de canales seguros.

    La instalacion de este MailMan suposo la instalar previamente: openssl,Net_SSLeay.pm,IO-Socket-SSL

  • Certificados para utilizar con stunnel. El servidor stunnel necesita un certificado x509 que utilizará para la negociación SSL con el cliente de correo. En el caso del GT como cliente de correo se utilizo MailMan.

Resultados

Modificaciones de cliente Pop de WebMail
Desafortunadamente los clientes POP/IMAP estudiados que incorporan TLS: Netscape y Outlook, no utilizan el sistema definido en el RFC 2595 para crear el canal cifrado entre el cliente y servidor. En lugar de mantener ese diálogo , establecen la negociación directamente en la conexión, comportándose como clientes http accediendo a un servidor http seguro. Los servidores son conformes con el RFC por lo que no existe compatibilidad entre estos clientes y servidores en el uso de TLS.

En la negociación de cifrado para el protocolo SMTP, Netscape y sendmail (versión 8.11) se ajustan al RFC 2487 usando el comando STARTTLS; Outlook establece una negociación TLS directa en la conexión no siendo compatible con sendmail.

En los clientes de correo basados en servidores web la información intercambiada entre cliente y servidor recorre dos caminos: en primer lugar va desde el cliente hasta el servidor web cuando se escriben los datos en la página html que actúa como cliente de correo. Posteriormente el servidor Web se convierte en cliente POP y envía los datos al servidor POP.

Este último punto fué lo que aporte esta I Fase del GTI-SMAIL, modificar un cliente Webmail, MailMan de Endymion, al que se le incorporó en el código las facilidades para establecer túneles SSL con servidores POP y SMTP. Este código está actualmente en trámites con la Empresa Endymion para que pueda ser distribuido a las instituciones de RedIRIS.

En último término s las instituciones de RedIRIS que tenga stunnel en el servidor POP y quieran ofrecerselo a sus usuarios se podría habilitar en el Servicio SAUCE de redIRIS para que los usuarios móviles que lo usan puedan crear un canal seguro entre la dirección IP donde se encuentren y el servidor POP de dicha Institución. En caso contrario dicho canal seguro solo existirá entre la dirección IP y el servidor de RedIRIS donde reside SAUCE y que actuará como cliente POP contra el servidor de la correspondiente Institución.

Si alguna institución dispone de una servidor POP con SSL se puede dar de alta en Servicio SAUCE de redIRIS se puede poner en contacto con:

postmaster@rediris.es

Configuración e instalación de Stunnel
El documento INSTALL del paquete fuente (ftp://stunnel.mirt.net/stunnel) contiene las intrucciones para la compilación.

Las intrucciones comunes de compilación:


./configure (con --help para ver las opciones)
make
make install
Probar el funcionamiento con: 

./stunnel -f -d  -r :
La configuración tiene dos partes:

Preparar el arranque con una de estas opciones:

  1. Instalar el demonio en los ficheros de arranque. Por ejemplo en: 

     /usr/sbin/init.d/stunnel-pop

    El contenido será algo así: 

            /local/stunnel -d 995 -r localhost:110

  2. Modificar /etc/services y /etc/inetd.conf.

    Despues rearrancar inetd:

    (En /etc/services) pop3s        995/tcp # pop con ssl.
(En /etc/inetd.conf) pop3s  stream tcp nowait root /local/stunnel  -l /local/popper

Certificados
Al configurar con --with-ssl definimos la localización de la instalación de openssl, los certificados estarán en el subdirectorio /certs del directorio indicado. Por ejemplo ./configure with-ssl=/usr/local/ssl

En el fichero common.h podemos definir el nombre del certificado con DEFAULT_CERT .

También pueden redefinirse estos datos en el arranque de la aplicación con la opción -p pemfile El fichero .pem contendrá el certificado del servidor y la clave privada (sin cifrar):

                 -----BEGIN RSA PRIVATE KEY-----
                  [encoded key]
                 -----END RSA PRIVATE KEY-----
                 [empty line]
                 -----BEGIN CERTIFICATE-----
                 [encoded certificate]
                 -----END CERTIFICATE-----
                  [empty line]
El paquete stunnel contiene certificados de prueba y utilidades para generarlos.

Fase II del GTI-SMAIL

Introduccion

Existen una seria de extensiones de protocolos que ha ido apareciendo en los ultimos tiempos que proporciona nuevos sistemas de autenticacion de usurio como son: SASL y APOP.

SASL dispone de dos niveles de autenticación: el básico como plain y login, y los avanzados como CRAM-MD5. Los básicos no suponen mejoras en la seguridad puesto que los datos de usuario se codifican en base64, como esta función es reversible podría obtenerse el username y password de usuario en un ataque pasivo. Los avanzados utilizan funciones de codificación no reversibles que son inmunes a estos ataques.

APOP es una extensión que aparece en el RFC 1939 donde se define el protocolo POP, es equivalente al nivel avanzado SASL. No es aplicable a ningún otro protocolo de acceso al buzón y está incorporado en el servidor qpopper y en los clientes Eudora.

Tanto APOP como los sistemas avanzados de autenticación SASL están basados en el mismo principio:

El usuario y el servidor comparten un secreto; cuando llega el momento de la autenticación el servidor envía un desafío al usuario basado en el secreto común. Solamente quien conoce dicho secreto puede resolver este desafío.

En este caso, el password no sale ni del servidor ni del cliente, es decir, no viaja por la red. Aunque se produzca un ataque pasivo que pudiera recoger una colección de desafíos y respuestas, no es posible descubrir el secreto ya que la función que genera la respuesta no es reversible. Como el desafío es único y se genera para cada sesión, tampoco es posible volver a utilizar una respuesta capturada.

En los protocolos de acceso al buzón (POP e IMAP) ya existían mecanismos de autenticación: username y password, equivalentes al nivel básico de SASL. Para mejorar la seguridad deberíamos utilizar niveles avanzados SASL, o usar APOP.

Con la autenticación SASL incorporada en los servidores SMTP podemos reservar el acceso a estos servidores a los miembros de la organización.

Podemos incluir mecanismos de autenticación en las relaciones de confianza respecto a clientes locales que se aplican actualmente, volviendo a definiendo las condiciones como:
Rechazar todo el correo cuyo origen sea una máquina externa a la organización y el destino sea una dirección también externa, cuando el usuario no este autenticado.

Con estas mejoras solucionamos el problema de la circulación del password en claro y del uso correcto de los servidores SMTP2, pero nos queda pendiente el problema de la transmisión del mensaje en claro por la red.

Objetivos

La segunda fase de este Grupo de Trabajo se centrara fundamentalmente en buscar tecnicas de autenticacion como SASL y su aplicacion practica en los servidores y clientes mas extendidos. Los objetivos que se pretenden resolver en esta II Fase del GTI-SMAIL son:

  • Para SMTP: conseguir un configurador para Sendmail que incorpore:
    • TLS para el cifrado de la comunicación.
    • SASL para la autenticación personal.
    • Medidas Anti-Relay que garanticen el uso correcto de las pasarelas.
  • Para los protocolos POP e IMAP crear un catálogo de servidores:
    • Que incorporen cifrado o autenticación.
    • Con documentación sobre configuración e instalación.
  • Para los clientes crear un catálogo:
    • De los clientes que incorporan cifrado o autenticación.
    • Documentación de configuración.
Para la configuracion del Sendmail se partira de un estructura de correo-e standard para uns institucion de RedIRIS.

Resultados

[Operativo]

Material

RFcs

1957 Some Observations on Implementations of the Post Office Protocol (POP3). R. Nelson. June 1996. (Format: TXT==2325 bytes) (Updates RFC1939) (Status: INFORMATIONAL)

2195 IMAP/POP AUT Horize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. September 1997. (Format: TXT=10468 bytes) (Obsoletes RFC2095) (Status: PROPOSED STANDARD)

2444 The One-Time-Password SASL Mechanism. October 1998. (Update: RFC2222) (Status: PROPOSED STANDARD)

2444 The One-Time-Password SASL Mechanism. October 1998. (Update: RFC2222) (Status: PROPOSED STANDARD)

2449 POP3 Extension Mechanism. R. Gellens, C. Newman, L. Lundblade. November 1998. (Format: TXT=36017 bytes) (Updates RFC1939) (Status: PROPOSED STANDARD)

2487 SMTP Service E xtension for Secure SMTP over TLS. P. Hoffman. January 1999. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD)

2554 SMTP Service Extension for Authentication. J. Myers. March 1999. (Format: TXT=20534 bytes) (Status: PROPOSED STANDARD)

2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. (Format: TXT=32440 bytes) (Status: PROPOSED STANDARD)

2831 Using Digest Authentication as a SASL Mechanism. P. Leach, C. Newman. May 2000. (Format: TXT=58124 bytes) (Status: PROPOSED STANDARD)

Drafts

SASL GSSAPI Mechanisms, J. Myers, 03/24/1999 (14524 bytes)
Simple Authentication and Security Layer [SASL] es una método para añadir soporte de autenticación a protocolos basados en conexión. Este documento describe el método de usar Generic Security Service Application Program Interface [GSSAPI] en SASL.

The SecurID(r) SASL Mechanism, M. Nystrom, J. Brainard, 1/13/1999 (19300 bytes)
Este documento define SASL en protocolos de autenticacion dinámicos (Security Dynamics' SecurID ) Este mecanimos solo afecta a la autenticación y no tiene ningún efecto sobre la encriptación.

X.509 Authentication SASL Mechanism, S.E. Kille, 1/1999 (20975 bytes)
Este documento definee SASL con autenticación X.509.

Documentación

Material
webbered
Actualizado el 10/11/2000
RedIRIS © 1994-2003
 ^