Diferencias entre un certificado para OWA TLS/SSL y un certificado para cifrar correos
Por Jesus Gutierrez – Revisado por: Daniel Seveso
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:
- 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.
- 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: https://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 https://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 https://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.7