En esta oportunidad veremos como redirigir los accesos al OWA para que los usuarios sólo tengan que acceder al servidor web ingresando http://nombredeservidor/, sin la necesidad de agregar el /Exchange al final.
De esta manera, facilitaremos mucho el acceso pudiendo, por ejemplo, crear un registro en el DNS para que se acceda via http://webmail.dominio.com/

Redirigir automáticamente las peticiones a /Exchange

Luego de hacer estas configuraciones, los usuarios podrán acceder al Webmail sin la necesidad de tipear /exchange en el browser:

1. Abrir la consola de Internet Information Server (IIS6) desde las Administrative Tools.
2. Expandir Web Sites
3. Hacer clic con el botón secundario del Mouse sobre el Default Web Site y seleccionar Propierties.
4. Seleccionar la solapa “Home Directory”.
a. Seleccionar “A redirection to a URL”
b. En el campo “Redirect to” escribir /Exchange
c. Tildar “A directory below URL entered” 

Reenviar peticiones http a https: 

Luego de configurar los siguientes pasos, IIS automáticamente redirigirá las peticiones http a https, con lo cual los usuarios no deberán ingrear https:// en la barra de direcciones. Previamente debemos haber instalado un certificado para SSL y configurado en los directorios virtuales de Exchange.

1. Crear una carptea en c:\inetpub\wwwroot llamada owaasp
2. Descargar el archivo owahttps.zip y descomprimirlo en la carpeta previamente creada
3. Abrir la consola de Internet Information Server (IIS6) desde las Administrative Tools
4. Expandir sites, expandir Default Web Site.
5. Sobre el directorio virtual Exchange hacer clic con el botón secundario del Mouse y seleccionar Propierties.
6. Ir a la solapa Custom Errors
7. Buscar de la lista 403;4 y seleccionar Edit
8. En Message Type Seleccionar URL, escribir /owaasp/owahttps.asp, y aceptar todas las ventanas.

9. Ubicar el directorio OWAASP dentro del Default Website

10. Hacer clic con el botón secundario del Mouse y seleccionar Propierties.
11. En la sección Application Settings hacer clic en Create y luego seleccionar ExchangeApplicationPool en el campo “Application Pool”.

Espero que les haya sido útil,

Saludos,
Vernocchi Pablo

Ya tenemos todo configurado. Entendemos las diferencias entre las distintas posibilidades dentro de la seguridad ofrecida por estándares y aplicadas en Exchange.

Hemos logrado firmar un mensaje digitalmente y asegurarnos que el contenido no fue modificado en tránsito pero… ¿qué pasa si alguien más está husmeando las conexiones?

Acá les pego una porción de una conexión smtp con un mensaje sin cifrar:

Y acá tenemos los resultados de una comunicación estándar entre un servidor Exchange y un servidor de un tercero:

Si juntamos todos los pedazos de conexión obtenemos:

Así es, ese texto lo puede leer cualquiera que se interponga entre nuestro servidor y el servidor de destino. Pero, para todas los problemas tenemos una solucón.

En esta oportunidad, veremos como proteger la confidencialidad de un correo, evitando que cualquiera lo pueda leer, y veremos su resultado.

El primer intento de cifrar un mensaje, puede no ser tan exitoso:

Y justamente se debe a que el usuario de destino no tiene un certificado, por lo tanto no tenemos acceso a sus claves para cifrarlo. Sin mucho más, se le otorga un certificado a ese usuario y con eso se resuelve el inconveniente.

Para esta demo, iniciamos sesión con el usuario Jorge, e intentamos enviar un mail cifrado a Pablo:

También veremos en la pantalla un ícono diferente, pero esta vez azul, informando que el correo está encriptado:

Como medida de seguridad, ese mensaje no es accesible via “Vista previa”, solamente se puede leer al abrirlo:

Y, al abrirlo, nos encontramos con un batallón de íconos y candados:

Al hacer clic sobre el ícono azul, que indica encripción, podemos ver los detalles del certificado, aí como también el nivel de encripción utilizado:

Y ahora, la prueba final. Sniffeando una conexión SMTP enviando un correo encriptado, obtenemos los siguientes resultados:

Cumplimos nuestra meta, ahora el mensaje se transmite de manera tal que no se puede interpretar a simple vista.

Saludos,
Vernocchi Pablo

En esta oportunidad veremos algunos aspectos en cuanto a seguridad en los mensajes.

Un poco de historia:
Con el crecimiento de Internet en los últimos 10 años, el correo electrónico ha sufrido un cambio en su utilización. Ya no es más una herramienta de mensajería interna en empresas, sino que se ha difundido en todos nosotros.

El protocolo adoptado para transmitir los correos fue SMTP (Simple Mail Transfer Protocol). El estándar SMTP posibilita el intercambio de correos desde diferentes plataformas. Históricamente este protocolo fue diseñado para enviar mensajes cortos, sin confidencialidad en redes cerradas, y principalmente no diseñado para transmitir información sensible através de una red mundial, como Internet. Básicamente SMTP transporta los mensajes de una manera que cualquiera puede leerlos (clear text).

S/MIME (Secure/Multipurpose Internet Mail Extension) fue desarrollado como estándar para reforzar la seguridad y confidencialidad de SMTP.
S/MIME fue desarrollado en 1995 por un grupo de vendors de seguridad. Fue una de las tantas especificaciones, como PGP. En 1998 se desarrolló la segunda versión de S/MIME, a diferencia de la versión 1 ésta ya estaba por considerarse como un estándar. En 1999, la versión 3 fue propuesta por la IETF con una serie de especificaciones técnicas.

S/MIME 3 fue altamente aceptado y los productos Microsoft que lo soportan son:

Microsoft Outlook 2000 SR-1 y superior
Microsoft Outlook Express 5.01 y superior
Microsoft Exchange 5.5 y superior

Qué beneficios brinda S/MIME?:

S/MIME provee dos servicios de seguridad: Firma digital y encripción de mensajes.
Estos dos servicios son la base en la seguridad en mensajes y los veremos en detalle a continuación:

Firma Figital
La firma digital es la contrapartida de la firma en un documento en papel. Como en las firmas legales, la Firma Digital provee:

* Autenticación: Valida la identidad. Como no hay autenticación en SMTP, no hay manera de saber quién envió el mensaje. Autenticación en una firma digital resuelve ese problema, permitiendo al destinatario del mensaje asegurarse que el mensaje fue enviado or quien dice haberlo enviado.

* No repudiación: Por ser única, la firma digital evita que el remitente del mensaje lo desconozca.

* Integridad de información: La integración de información es el resultado de una operación específica que hace posible la firma digital. Cuando el mensaje es enviado, se calcula el hash del mensaje. Cuando se recibe, el hash es calculado nuevamente y, si el mensaje fue modificado en tránsito, da un error en la firma digital.

***NOTA***: Muchos softwares que agregan discalimers a los mensajes hacen que las firmas digitales sean inválidas, ya que son modificados en tránsito cuando se les agrega la nota de pie de mensaje.

Los pasos, en líneas generales son:

Y cuando el mensaje es recibido, el cliente realiza lo siguiente:

Encripción de mensajes:

La encriptación del mensaje prevee una solución para evitar que terceros puedan tener acceso al contenido del mensaje, ya que el correo SMTP se transporta en texto plano.

Encriptar es el proceso de modificar el contenido para que no sea leído o entendido hasta que no se revierta la alteración producida. De esta manera encriptar un mensaje nos provee:

* Confidencialidad: Proteje el contenido del correo. Sólo el destinatario seleccionado puede desencriptar el correo y poder leerlo. Éste método provee confidencialidad mientras el mensaje está en tránsito o almacenado.

* Integridad de la información: Como en la firma digital, encriptar un correo provee integridad de información, como resultado de las operaciones que se efectúan sobre el mismo.

Al momento de enviar un correo, los pasos son los siguientes:

Y cuando se recibe:

Aunque encriptar el contenido del mensaje provea confidencialidad e integridad, no autentica el remitente de ninguna manera. Un mensaje encriptado, pero sin firma digital sufre los mismos problemas de suplantación de identidad que el correo común.

Rights Management Services (RMS):

Como alternativa tenemos un servicio llamado RMS. Dentro de los beneficios de implementar una solución basada en RMS, podemos encontrar:

 * Proteger la información confidencial contra un acceso o uso compartido con usuarios no autorizados

* La capacidad de controlar no únicamente el acceso a los datos, sino la manera en que se utilizan y distribuyen.

* Garantizar que el contenido de los datos esté protegido y sea resistente a la manipulación

* La capacidad de controlar la fecha de caducidad de los contenidos

Un mensaje protegido por RMS no puede ser reenviado, ni impreso. Cuando respondemos sobre ese mismo mensaje, el cuerpo original es eliminado. Además las funciones de captura de pantalla están deshabilitadas. No se puede mostrar en paneles de vista previa y no se muestran las primeras líneas del mensaje en la advertencia de escritorio de Outlook 2003.

En resúmen, podemos destacar las siguientes diferencias entre S/MIME y RMS:

La intención de esta primer parte es que puedan distiguir entra todas las alternativas de seguridad de mensajería que soporta Exchange..

Próximamente estaré mostrando cómo implementar todo esto, S/Mime y RMS en acción.

Saludos,
Vernocchi Pablo