¿Cómo funciona TLS?

En este post mostraremos los principios y conceptos básicos para comprender el funcionamiento de TLS en una conversación SMTP. Tome en cuenta que los mismos conceptos / algoritmos / mecanismos son igualmente válidos para el cifrado por TLS / SSL en otros protocolos como HTTPS.

SMTP Client   SMTP Server Protocolo
Esperando conexión…   220 server.company.com Microsoft ESMTP MAIL Service ready SMTP
EHLO domain.com   250-server.company.com Hello [192.168.75.1]

250-SIZE

250-PIPELINING

250-DSN

250-ENHANCEDSTATUSCODES

250-STARTTLS

250-X-ANONYMOUSTLS

250-AUTH NTLM

250-X-EXPS GSSAPI NTLM

250-8BITMIME

250-BINARYMIME

250-CHUNKING

250-XEXCH50

250 XRDST

SMTP
STARTTLS   220 2.0.0 SMTP server ready SMTP
ClientHello   ServerHello

Certificate*

ServerKeyExchange*

CertificateRequest*

ServerHelloDone

TLS
Certificate*

ClientKeyExchange

CertificateVerify*

[ChangeCipherSpec]

Finished

  [ChangeCipherSpec]

Finished

TLS

 

Application Data   Application Data SMTP sobre TLS
*Opcionales      

 

La comunicación por TLS se da dentro de los siguientes pasos:

  1. Un SMTP Client se conecta a un SMTP Server. Este paso se realiza de forma normal como en cualquier transacción de SMTP cuando un MTA tiene un correo listo para ser entregado. El MTA determina la ruta de entrega, que consiste en resolver el registro MX del dominio destino y así ubicar la dirección IP del SMTP Server. Una vez que cuenta con la IP, realiza una conexión directa al puerto 25 y espera al banner de bienvenida del servidor, indicado por un código 220.
  2. Ambos hosts inician la comunicación por SMTP. En este punto el SMTP Client envía el comando de saludo EHLO seguido de su FQDN. Este paso sirve para que el SMTP Server sepa el nombre del servidor ó dominio del cual se recibirá un nuevo correo. El SMTP Server responde al saludo con un listado de todos los comandos / mecanismos que es capaz de soportar, y en caso de soportar TLS ofrece una línea con el nombre del comando STARTTLS. Cuando el SMTP Client encuentra esta línea, tiene la opción de mandar el correo en texto claro (enviando como siguiente comando el de MAIL FROM) ó comenzar una transferencia segura por TLS (enviando el comando STARTTLS).
  3. El SMTP Client inicia el establecimiento de la sesión por TLS. Si el SMTP Client es capaz de soportar la comunicación por TLS, el siguiente comando que envía es STARTTLS. Dependiendo de la configuración, el SMTP Server puede estar configurado para recibir únicamente correos a través de TLS, en cuyo caso, si el SMTP Client envía un comando MAIL FROM, recibirá un código de error indicando que primero debe enviar el comando STARTTLS. Si el SMTP Client no soporta TLS, abortará el envío de correo hacia ese dominio y generará una notificación de no entrega  (NDR: Non-Delivery-Response) al remitente. De aceptar satisfactoriamente el comando STARTTLS, el SMTP Server deberá responder que está listo para iniciar el cifrado del canal con TLS. Este es el último punto en la transferencia del correo en que la comunicación es SMTP pura, a partir de aquí, la información no se transmite en texto claro y ya no es legible para un usuario que pudiera estar interceptando la conversación con un sniffer. En este punto ambos servidores cambian de rol a TLS Client y TLS Server.
  4. El TLS Client inicia el TLS Handshake Protocol. Aquí envía un listado de todos los algoritmos de cifrados que es capaz de manejar e interpretar.
  5. El TLS Server responde al saludo de TLS. En este punto el TLS Server escoge alguno de los algoritmos indicados por el TLS Client y comienza el envío de información para cifrar el canal. Entre los datos que se pueden enviar se encuentra el certificado digital.
  6. El TLS Client verifica el certificado del servidor. Revisa la firma digital del certificado y si es válida, el TLS Client puede confiar en que el TLS Server cuenta con un certificado firmado por un tercero que ambos conocen y en el que ambos confían.
  7. El cliente verifica el nombre del servidor. El cliente utiliza el certificado del servidor para comparar el campo Subject con el FQDN del TLS Server. Si ambos coinciden, el cliente puede estar seguro de que el servidor con el que se está comunicando es realmente quien dice ser y no algún otro equipo en el medio.
  8. El cliente y el servidor cambian a comunicación cifrada. Es hasta este momento en que el canal ha quedado listo para ser utilizado. Ahora comienza la transferencia normal del correo con la conversación SMTP tradicional, teniendo la confianza de que los datos intercambiados no podrán ser vistos por alguna entidad fuera del canal TLS. Aquí la comunicación se reinicia y comienza nuevamente con el comando EHLO.
  9. La sesión termina. En este punto, el SMTP Client ha enviado todos los correos que tenía para el SMTP Server por lo que el túnel TLS se destruye. El SMTP Server queda en espera de una nueva conexión SMTP.

Certificados Digitales

Un certificado digital es un bloque de información que contiene datos privados utilizados en el proceso de identificar de forma única a una entidad. En TLS, existen al menos tres tipos de certificados que son utilizados para cumplir los siguiente objetivos:

  • Autenticación. El certificado digital intercambiado entre ambas partes está firmado por una entidad en la que ambos, el TLS Client y el TLS Server confían, por lo que se puede asegurar que el TLS Server es realmente quien dice ser.
  • Integridad. El cifrado de paquetes se realiza con un Master-Secret que sólo puede ser conocido por ambos servidores. Antes de cifrar el paquete, se saca un hash, el cual es firmado por el Master-Secret. Cada vez que se recibe un paquete, el hash es descifrado con el Master-Secret y se verifica que el hash recibido coincida con el hash actual del paquete, si la verificación es satisfactoria se puede asegurar que el paquete no fue alterado durante su camino.

El modelo de operación es el siguiente:

  1. El servidor “host1” comienza el proceso de creación de su certificado al generar primero una llave privada. Esta llave no es más que una secuencia numérica que obedece a un algoritmo matemático, de forma tal, que cualquier mensaje que sea cifrado con esta llave privada sólo puede ser des-cifrado con la correspondiente llave pública (esta llave se puede generar en paralelo o en un proceso posterior). Debido a su criticidad en la privacidad de la comunicación, esta llave debe estar bien resguardada y no debe compartirse bajo ningún motivo.
  2. El servidor “host1” utiliza su llave privada para generar un “Certificate Request” ó “Solicitud de Certificado”. Durante su generación, se emplea un algoritmo matemático que calcula la llave pública correspondiente a la llave privada obtenida en el paso anterior. La solicitud es enviada a una entidad certificadora que tanto “host1” como “host2” conocen.
  3. La entidad certificadora “ca-ca.com” recibe la solicitud de certificado. Como respuesta, generará un certificado público para “host1” que contiene la firma digital de la propia entidad certificadora. Esta firma digital se genera haciendo un hash del certificado público y después cifrándolo con la llave privada de la propia entidad certificadora, el resultado se anexa al certificado público para que pueda ser comparado cuando el certificado se valide. Cualquier entidad que quiera validar la autenticidad del certificado público de “host1” deberá generar el mismo hash sobre todo el certificado y después firmar ese hash con la llave pública de la entidad certificadora, el resultado se compara contra la firma digital presente en el certificado público, si ambas firmas coinciden entonces se puede asegurar que el certificado fue realmente firmado por ca-ca.com y que el certificado público fue realmente emitido para “host1”. Es esta fase la que permite la autenticación del servidor “host1” por cualquier otro servidor en posesión de la llave pública de la CA.
  4. Una vez que la CA ha firmado el certificado, se lo entrega a “host1” para que lo comparta con cualquier otra entidad con la que deseé entablar comunicaciones por TLS.
  5. El servidor “host2” comienza la transferencia de un correo nuevo por TLS con “host1”. Como respuesta a esta solicitud, “host1” responde con su certificado público firmado por ca-ca.com, de forma que “host2” pueda verificar si puede o no confiar en que “host1” es realmente “host1”.
  6. Al obtener el  certificado público, “host2” primero extrae el nombre de la CA que firmó el certificado, en nuestro caso ca-ca.com. Una vez que conoce el nombre, “host2” verifica en su repositorio de certificados si cuenta con el certificado raíz de ca-ca.com. De tenerlo, extrae la llave pública de ca-ca.com para generar el hash del certificado y después cifrarlo con esa llave pública. El resultado es comparado contra la firma digital presente en el certificado público y de ser idénticos, “host2” puede estar seguro de que hay un tercero en que confía (la entidad certificadora) y que certifica que la máquina que mandó ese certificado público es realmente quien dice ser. En caso de que la comparación de las firmas digitales no sea satisfactoria o que no se cuente con el certificado raíz de ca-ca.com, “host2” no puede asegurar que “host1” es realmente “host1” porque no hay un  tercero que pueda certificarlo. En este caso “host2” debe decidir entre continuar con la creación del canal cifrado por TLS o abortar la transferencia del correo. El último paso en la verificación de la identidad de “host1” es extraer el nombre del host que viene en el certificado público, este nombre debe ser idéntico al FQDN con que “host1” se identifica al momento de responder al comando “EHLO”. Si los nombres no coinciden entonces se asume que el certificado es válido pero no fue emitido a nombre de “host1”, en este punto “host2” debe decidir entre continuar con la sesión o abortar.
  7. Si la verificación del certificado es satisfactoria el TLS Client y Server pueden comenzar la creación del túnel cifrado y transferir el correo de forma segura.

Para que este modelo funcione en la práctica es necesario entonces que las tres partes involucradas (TLS Client, TLS Server y CA) cuenten con los certificados correctos. En la siguiente tabla se pone la distribución de los certificados de acuerdo al rol y al tipo de transferencia.

Rol Certificados Uso
TLS Client
  • Certificado Raíz de la CA
Se utiliza para extraer la llave pública de la CA con el fin de comprobar la firma digital del certificado público del TLS Server.
TLS Server
  • Certificado Público
Es enviado en cada sesión TLS para que el TLS Client pueda verificar la identidad del TLS Server.
  • Llave privada (certificado privado)
Esta llave es utilizada al momento de generar la solicitud de certificado. Después de generado el certificado la llave se usa para descifrar los paquetes que el TLS Client cifró con la llave pública del TLS Server.
CA
  • Certificado Raíz de la CA
Una CA siempre debe mantener accesible este certificado para que cualquier entidad pueda descargarlo y así verificar los certificados firmados por ella.
  • Llave privada (certificado privado)
La CA utiliza esta llave para crear la firma digital de los certificados que emite.

Después de revisar estos conceptos podemos sacar las siguientes conclusiones:

  • El TLS Server es el que debe tener un certificado público.
  • El TLS Client sólo necesita contar con el certificado raíz de la CA para validar el certificado público.
  • Los certificados digitales son opcionales cuando se transfiere un correo electrónico por TLS. Esto es cierto únicamente cuando el algoritmo criptográfico para el intercambio de llaves es DHE_anon, en todos los demás casos se necesita de un certificado. Éste puede cumplir la función de autenticación, firmado ó ambas.
  • Los certificados digitales no se utilizan para cifrar el canal. TLS tiene un mecanismo de cifrado síncrono que permite que ambos servidores intercambien una llave que utilizarán para cifrar el canal. Los certificados se utilizan para intercambiar la información que generará dicha llave (Master-Secret).

Generación del Master Secret

El Master-Secret es una parte crucial en cualquier comunicación por TLS. Esta será la llave que ambos servidores utilizarán para cifrar / descifrar la conversación SMTP. Se genera de acuerdo al método seleccionado en el paquete cipher-suite.

Cipher Suite. Es una lista ordenada de todos los mecanismos criptográficos que el TLS Client es capaz de soportar. El orden de la lista corresponde a la prioridad en la que deberían ser elegidos, siendo el primero en la lista el que debería tener más probabilidades de ser elegido por el TLS Server. Los parámetros en estas listas indican el algoritmo utilizado para el intercambio de llaves (RSA, DH, DHE, etc..), el algoritmo utilizado para cifrar los mensajes (AES, DES, RC4, etc..) y el algoritmo de HASH utilizado para firmar cada mensaje (SHA ó MD5).

tls1

El tipo de cifrado de TLS que se realice entre los dos servidores dependerá de estas combinaciones. El orden y el tipo de cifrado se detallan a continuación.

Cuando se genera el Master Secret el único algoritmo que cuenta es el proporcionado en la sección Key_Exchange. Estos se pueden clasificar en tres grupos:

Intercambio de llaves anónimo. Esta suite se identifica porque comienza con “TLS_DH_anon_WITH”. En esta suite, no existe autenticación de los servidores, es decir, no hay intercambio de certificados digitales. Esto se debe al uso del algoritmo Diffie-Hellman (DH) cuyo propósito es el intercambio de información sensible entre dos entidades a través de un canal inseguro. En teoría el algoritmo no necesita de certificados públicos para autenticar a los servidores porque está diseñado para que dos entidades que no se conocen puedan intercambiar ciertos valores que de acuerdo al algoritmo permitirán que ambos coincidan en un mismo secreto. A continuación se muestra un ejemplo del algoritmo:

Alice Bob
Secret Public Calculates Sends Calculates Public Secret
a p, g p,g b
a p, g, A ga mod p = A A p, g b
a p, g, A B gb mod p = B p, g, A, B b
a, s p, g, A, B Ba mod p = s Ab mod p = s p, g, A, B b, s

                                 Tabla 6. Algoritmo Diffie-Hellman. Fuente Wikipedia

En este algoritmo los dos servidores escogen un “Pre-Secret” que es un número generado por una función pseudo-aleatoria (PRF – Pseudo Random Function). Este número sólo es conocido por cada servidor y debe ser generado de tal forma que no exista posibilidad (o sea muy remota) de que el número vuelva a repetirse. Después ambos servidores intercambian un par de números que serán conocidos por ambos, aquí el TLS Client manda un paquete ClientKeyExchange y el TLS Server un ServerKeyExchange. A partir de esta información pública, el algoritmo permite que ambos servidores calculen exactamente un mismo número que será el Master-Secret sin necesidad de que éste viaje por el canal inseguro y pueda ser interceptado por algún atacante. Tome en cuenta que aunque un atacante puede interceptar la información pública de la comunicación no será capaz de calcular el mismo Master-Secret porque cada servidor generó su propio Pre-Secret de forma privada. Este tipo de comunicación no se recomienda en transacciones por Internet por el hecho de carecer de autenticación, es decir, aunque es posible cifrar el canal, no es posible autenticar la identidad de ninguno de los servidores.

 

Autenticación e Intercambio de llaves RSA. En este modo, existe un intercambio de certificados RSA que permiten tanto la autenticación de los servidores como el intercambio de llaves. Se identifican por comenzar con la secuencia “TLS_RSA_WITH_”. La autenticación del TLS Server se realiza extrayendo la firma digital del certificado y comparándola contra la firma digital generada por el propio TLS Client. Para que la validación sea satisfactoria, el TLS Client debe contar con el certificado raíz de la Entidad Certificadora (CA – Certificate Authority) debido a que en dicho certificado se encuentra la llave pública de la CA. La firma digital se obtiene haciendo un HASH del certificado público del TLS Server y después cifrándolo con la llave pública de la CA que generó el certificado, si la firma es válida significa que el certificado del TLS Server fue realmente firmado por una CA en la que nosotros confiamos. Adicionalmente se puede comparar el FQDN especificado en el comando EHLO contra el FQDN que aparece en el campo Subject del certificado. Al verificar el certificado digital se tiene la certeza de que la CA que lo firmó realmente expidió dicho certificado a nombre de ese servidor, sin embargo, cualquier otro servidor podría aún hacerse pasar el TLS Server, por lo que se necesita de una última prueba para verificar que sólo el TLS Server tiene en su poder la llave privada que corresponde a la llave pública del certificado. Para esto, el TLS Client cifra su Pre-Master con la llave pública, si el TLS Server realmente tiene la llave privada, será el único que podrá descifrar el paquete, extraer el Pre-Master y generar el Master-Secret para cifrar el canal. Esta fase evita que cualquier máquina / aplicación que esté en el medio, pueda simplemente estar retransmitiendo los paquetes de y hacia ambos servidores.

Adicional a la autenticación del TLS Server, también se puede autenticar al TLS Client. En este caso el TLS Server debe solicitar el certificado del cliente con un paquete CertificateRequest. El TLS Client cifra con su llave privada algunos valores previamente recibidos como el certificado público del TLS Server y los envía con su propio certificado público. El TLS Server debe descifrar el mensaje usando la llave pública contenida en el certificado del cliente, de ser satisfactoria, ambos servidores estarán autenticados.

Tome en cuenta que la autenticación del cliente no es obligatoria y de hecho no es recomendable, ya que no todos los clientes están configurados con un certificado ó con los mecanismos necesarios para responder a esta solicitud, en cuyo caso toda la comunicación es abortada por el cliente.

tls2tls3El intercambio de llaves se lleva a cabo cuando el TLS Client, después de validar el certificado público del TLS Server, cifra su propio Pre-Secret con la llave pública del certificado, si dicho certificado corresponde al TLS Server, entonces este debe ser el único en posesión de la llave privada correspondiente. En este caso el TLS Server usa su llave privada para descifrar el Pre-Secret, ahora ambos servidores están listos para generar el mismo Master-Secret que se usará para cifrar los paquetes.

 

Autenticación con Intercambio de llaves Diffie-Hellman. Estos algoritmos se identifican por comenzar con “TLS_DHE_DSS_WITH_”,  “TLS_DHE_RSA_WITH_”, “TLS_DH_DSS_WITH_” y “TLS_DH_RSA_WITH_”. En este modo, el servidor puede enviar un certificado que contiene los parámetros Diffie-Hellman ó puede mandar sus parámetros en el paquete ServerKeyExchange firmados con su llave privada. Si el servidor utiliza la primera opción, entonces se dice que este certificado no sirve para autenticar, sólo para firmar, ya que sólo contiene los datos DH para el intercambio del Pre-Secret, la autenticación se realiza al recibir el paquete Finished firmado con el Master-Secret que sólo podría ser conocido por ambos. En el segundo caso, el certificado sirve tanto para firmar los paquetes como para autenticar, tal y como en intercambio por RSA.

 

Algoritmo de cifrado de paquetes (Generación de la llave Master Secret)

A diferencia del cifrado asimétrico utilizado en el intercambio de llaves donde se ocupan tanto llaves públicas como privadas, el cifrado de los paquetes se realiza con cifrado simétrico donde las operaciones de cifrado y descifrado en ambos servidores se realiza usando la misma llave: el Master-Secret. La fase de intercambio de llaves sólo sirve para intercambiar la información necesaria para generar este secreto, la forma en que se calcula en ambos servidores es:

Master-Secret = PRF (pre_master_secret, “master_secret”, ClientHello.random + ServerHello.random)

 

Si deseas profundizar más en los conceptos ó implementación de TLS te recomendamos nuestra publicación Fundamentos del Protocolo TLS. Si deseas mayor información sobre las reglas de creación / transmisión / recepción del correo electrónico también te recomendamos nuestra publicación sobre Fundamentos de Correo Electrónico.

Recuerda que puedes enviarnos tus preguntas y comentarios a nuestra cuenta de Twitter:@redinskala donde encontrarás más información y tips de seguridad.

Gracias por tu visita!