Diferencias entre un certificado para OWA TLS/SSL y un certificado para cifrar correos

En ocasiones
recibimos casos de soporte donde al cliente le preocupa que la información
relativa a correo electrónico sea transmitida de forma segura, una creencia
común es que usar un certificado para el servicio de OWA, Autodiscover, Active
Sync, RPC-Https, funciona para “cifrar” la información sin embargo, una
pregunta que recibimos a menudo es cómo proteger el contenido de los mensajes
para que sólo la persona a la que se desea enviar la información pueda verla.

El siguiente
documento explica la diferencia ente un certificado para encriptar la
comunicación en un ambiente Cliente – Servidor como es el caso de OWA en
Exchange 2007 – 2010 y un certificado para encriptar el contenido de un correo
electrónico entre 2 usuarios.

Iniciemos por
explicar el certificado utilizado para la comunicación entre Cliente – Servidor

Comunicación
entre Cliente Servidor

Típicamente
usamos el puerto 443 para realizar la petición utilizando
https://correo.contoso.com/owa , el propósito de éste certificado es
cifrar la comunicación entre OWA (Servidor) y los browsers que consumen el
servicio de OWA, Autodiscover, Active Sync, RPC-https (Clientes) esto además
permite el cerciorarnos que la comunicación se está realizando con el servidor
correcto, con el servidor que intento comunicarme y no uno que pudiera fingir
ser el servidor.

Cuando el
nombre del certificado es el mismo que el nombre que utilizamos en la
dirección, Internet Explorer muestra la página sin ninguna advertencia.

Cuando el
nombre del servidor no es el mismo o existe un problema con el certificado,
Internet Explorer mostrará una advertencia.
“There
is a problema with This website’s Security certificate”

Éste
certificado tiene como uso el de Server / Client Authentication. Se utiliza un
Template de WEB Server que garantiza que estoy teniendo la comunicación con el
servidor que dice ser mail.microsoft.com como pueden ver no existe el atributo
SMIME.

Qué
elementos contiene este tipo de certificado?

Entre otras
cosas, como se mencionó anteriormente, el certificado permite asegurarnos que
estamos teniendo la conversación con el servidor que pretendemos y no con uno
falso.

Contiene la
fecha de validez del certificado así como la entidad certificadora que generó
el certificado. Típicamente es emitido por una entidad certificadora pública de
confianza.

El certificado
contiene un campo llamado Subject, este valor contiene el nombre del servidor
al que nos conectamos en el caso de Exchange 2007 , 2010 típicamente utilizamos
un certificado con nombres adicionales tal es el caso de
Autodiscover.contoso.com y legacy.contoso.com

Adicionalmente
existe el campo Key Usage / Enhanced Key Usage este campo determina el
propósito para el cual el certificado fue emitido. En el caso de OWA el
certificado tiene los valores de Client / Server Authentication.

Key Usage

Digital Signature, Key Encipherment (a0)

Enhanced Key Usage

Server Authentication (1.3.6.1.5.5.7.3.1)

Client Authentication (1.3.6.1.5.5.7.3.2)


El certificado
entonces permite entre otras cosas:

  • Garantizar que la comunicación
    se está teniendo con el servidor correcto

  • Cifrar la comunicación entre el
    cliente y el servidor

Es importante
aclara que éste certificado no cifrará la información contenida en los mensajes
es decir, si yo envío un correo electrónico del usuario A al usuario B el
contenido de ese mensaje no estará cifrado. Cuando yo mande el mensaje con el
servidor la información entre el cliente y el servidor estará cifrada más no el
contenido del mensaje.

Aclaremos el
punto, cuando establezco la comunicación con el servidor, nadie podrá saber qué
es lo que se está transmitiendo, sin embargo si yo hiciera un PST de mi carpeta
“elementos enviados” cualquier persona que tuviera acceso al PST podría ver el
contenido del mensaje que se envió al usuario B.

Para la
mayoría de los clientes esto es suficiente, una vez que la información ha sido transmitida
de forma segura al ambiente, otros mecanismos evitan que la información sea
vista por personas que no deban tener acceso sin embargo, algunos clientes
requieren protección sobre el contenido del mensaje para únicamente la persona
que debe conocer esa información pueda accederla. Es aquí donde muchos de ellos
optan por cifrar el contenido de la información.

Cifrado de
Correos Electrónicos

El certificado
para encriptar el contenido de los correos independientemente de si se usa,
OWA, Outlook, un Celular, una Tablet etc, es distinto al utilizado en la
publicación de servicios como owa, active Sync, Autodiscover rpc-https.

El propósito
de cifra el contenido del mensaje es proteger la información para que sólo el
destinatario (os) que deban conocer esa información lo pueda hacer.

Éste
certificado tiene las capacidades y el propósito de proteger el contenido de la
información así como la de validar la identidad del remitente. Típicamente se
usa una CA interna si se requiere proteger la información sólo con
destinatarios de la misma organización con el Template de USER o un certificado
emitido por una CA externa si se desea interactuar con personas externas a la
organización.

This certificate is intended for the following
purpose(s):

Allows data on disk to be encrypted

Protects e-mail messages

Proves your identity to a remote computer

Key Usage

Digital Signature, Key Encipherment (a0)

Enhanced Key Usage

Encrypting File System (1.3.6.1.4.1.311.10.3.4)

Secure Email (1.3.6.1.5.5.7.3.4)

Client Authentication (1.3.6.1.5.5.7.3.2)

Para poder
enviar un correo cifrado es necesario contar con la llave pública del usuario
destinatario
ya que esta llave es la que voy a emplear para encriptar el
contenido.

Cómo se
determina el algoritmo de encripción que se va a utilizar para cifrar el
mensaje? El primer paso a aclarar es, si mi Certificado personal puede
encriptar usando AES 256 bits y el destinatario tiene una llave RC240 bits yo
debo encriptar ese mensaje con una llave de 40 bits aunque mi certificado
tenga una llave de 256
ya que el destinatario solo conoce el algoritmo RC2
40 bits.

Cuál es el
mecanismo para seleccionar el algoritmo de encripción en OWA, Outlook?

Nuestros
productos tanto OWA como Outlook de forma predeterminada van a utilizar el
algoritmo más fuerte que el certificado y el sistema operativo conozcan.
Entonces
si el algoritmo más fuerte que el destinatario conoce y el sistema operativo
del que se está generando es AES, Outlook al momento de configurarse y OWA
enviarán el correo con AES 256 bits

Es importante
aclarar que, si el correo de envía desde un equipo 2003, XP el algoritmo
soportado por esta plataforma es 3DES. Por qué es importante conocer esto?

Imaginemos un
escenario como este:

  1. Desde OWA el usuario se firma en
    un equipo Windows 7, OWA detecta que el algoritmo más fuerte habilitado en
    el certificado del destinatario es AES 256, Windows 7 soporta AES 256
    entonces, envía el mensaje cifrado.

  2. El destinatario abre el mensaje
    en su equipo XP con recibirá un mensaje como este:

No se puede
descifrar este mensaje porque no se admite su algoritmo de cifrado o no se
encuentra el id. digital. Si tiene un id. digital basado en tarjeta
inteligente, inserte la tarjeta y intente abrir el mensaje de nuevo.

  • This
    message can´t be decrypted because its encryption algorithm isn´t
    supported or your digital ID can´t be Found

  • No se puede descifrar este
    mensaje porque no se admite su algoritmo de cifrado o no se encuentra el
    id. digital. Si tiene un id. digital basado en tarjeta inteligente,
    inserte la tarjeta y intente abrir el mensaje de nuevo.


Por qué? Por
qué Windows XP soporta como máximo 3DES:
http://technet.microsoft.com/en-us/library/bb738151.aspx










Outlook Web App volverá a la lista interna predeterminada. Esta lista
empieza por AES256 en los equipos que ejecutan Windows Vista y por 3DES en
los equipos que ejecutan Microsoft Windows XP.


Los algoritmos de AES sólo se usan si los admite el equipo del usuario.
AES no es compatible con Windows XP y los mensajes que se hayan cifrado con
AES no se podrán leer en los que equipos que ejecuten Windows XP.



Explicación


Outlook Web App intentará usar el algoritmo más fuerte con la mayor
longitud de clave disponible en el equipo del usuario. Si el algoritmo de
cifrado o la longitud de clave mínima no está disponibles en el equipo del
usuario, Outlook Web App no permitirá realizar el cifrado.


Este mismo
comportamiento es respetado por Outlook al momento de configurar las
características de SMIME

Cuando se
selecciona el certificado Outlook toma el algoritmo más fuerte que esté
soportado por el certificado y el SO.

En un ambiente

donde todos los usuarios en cuestión utilizarán un certificado emitido de la
misma forma siempre vamos a usar el algoritmo más fuerte disponible por el SO y
el Destinatario independientemente de que la lista muestre X algoritmos
disponibles.

Un usuario
tiene la oportunidad de publicar su certificado en la GAL y el AD de igual
forma:

Outlook leerá
primero el atributo userSMIMECertificate y seleccionará el certificado c, si no
encuentra un certificado leerá el atributo UserCertificate y hará la misma
selección.

OWA leerá
primero el atributo UserCertificate y seleccionará el certificado, si no
encuentra un certificado leerá el atributo userSMIMECertificate y hará la misma
selección.

Es ahí donde
se leen las capacidades de encripción del destinatario. Si el destinatario no
es parte de la organización (usuario externo) Outlook leerá las propiedades del
contacto con el certificado asociado

Algunas veces
nos hemos encontrado con casos de clientes en donde los usuarios tienen varios
certificados publicados en el AD, todos ellos válidos y con las capacidades Secure
Email (1.3.6.1.5.5.7.3.4)

Key Usage

Digital Signature, Key Encipherment (a0)

Enhanced Key Usage

Encrypting File System (1.3.6.1.4.1.311.10.3.4)

Secure
Email (1.3.6.1.5.5.7.3.4)

Client
Authentication (1.3.6.1.5.5.7.3.2)

Tal como lo
explica el blog
http://blogs.technet.com/b/pki/archive/2008/12/17/outlook-s-mime-certificate-selection.aspx y como se explicó
anteriormente

Outlook
buscará el atributo userSMIMECertificate primero y después UserCertificate, OWA
lo hace de forma inversa.
Nos hemos encontrado con errores como


  • No se puede abrir el elemento.
    El sistema de seguridad subyacente no puede encontrar el nombre del
    identificador digital.

  • Unable to
    open item. Security system cannot found the name of Digital ID

Esto
básicamente se debe a que la llave que se usó para cifrar el mensaje es de un
certificado diferente al que se está usando para descifrar el mensaje. Si es el
caso se pude publicar desde Outlook en la sección de SMIME los valores en
blanco para eliminar ese valor y nuevamente publicarlo con el certificado que
se desea utilizar.

Otra pregunta
que recibimos frecuentemente es el por qué el Template / plantilla de USER o
por qué los certificados tienen capacidades SMIME distintas a los algoritmos
que se muestran.

El ignorar el
SMIME Capabilities está previsto en el RFC Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.2 Message Specification
http://www.rfc-editor.org/rfc/rfc5751.txt)

… The semantics of the SMIMECapabilities attribute
specify a partial list as to what the client announcing the SMIMECapabilities
can support. A client does not have to list every capability it supports, and
need not list all its capabilities so that the capabilities list doesn’t get
too long. In an SMIMECapabilities attribute, the object identifiers (OIDs) are
listed in order of their preference, but SHOULD be separated logically along
the lines of their categories (signature algorithms, symmetric algorithms, key
encipherment algorithms, etc.)….

Otro detalle
es que esta lista de SMIME Capability no es un “requerimiento” es simplemente
lo que pone el default template de una CA de Windows 2003 si no se especifican
capacidades especiales.

[1]SMIME Capability

Object ID=1.2.840.113549.3.2

Parameters=02 02 00 80

[2]SMIME Capability

Object ID=1.2.840.113549.3.4

Parameters=02 02 00 80

[3]SMIME Capability

Object ID=1.3.14.3.2.7

[4]SMIME Capability

Object ID=1.2.840.113549.3.

Deja una respuesta