¿Cómo funciona SSL sin clave?

¿Qué es el SSL sin clave?

SSL sin clave es un servicio para empresas que usan un proveedor de soluciones en la nube para la encriptación SSL. Normalmente, el proveedor de la nube tiene que conocer la clave privada de la empresa, pero con SSL sin clave se puede eludir ese requisito. Por su normativa, muchas organizaciones no pueden compartir sus claves privadas. A pesar de ello, con SSL sin clave pueden usar TLS y sacar partido de la nube manteniendo su clave protegida.

SSL, también llamado de manera más precisa TLS, es un protocolo para autenticar y encriptar las comunicaciones a través de una red. SSL/TLS requiere el uso de lo que se conoce como una clave pública y una clave privada. Las empresas que usan este protocolo para proteger el tráfico entrante y saliente de su sitio web (ver HTTPS) suelen mantener la posesión de la clave privada. Pero cuando una empresa migra a la nube y el proveedor ofrece encriptación TLS, pasa a controlar también la clave privada.

Al realizar la parte del protocolo de enlace en la que se usa la clave privada fuera del servidor del proveedor, la clave privada permanece segura en posesión de la empresa. En lugar de utilizar la clave privada directamente para autenticar el servidor del proveedor, el proveedor de la nube reenvía los datos al servidor de la empresa y los recibe de él para llevarlo a cabo. Esta comunicación se produce a través de un canal seguro y encriptado. Por ello, se sigue utilizando una clave privada, pero no se comparte con nadie de fuera de la empresa.

Por ejemplo, supongamos que Acme Co. implementa TLS. Acme Co. almacenará de forma segura su clave privada en un servidor propio que controla por sí mismo. Si Acme Co. migra a la nube y utiliza un proveedor de servicios en la nube para el alojamiento web, ese proveedor tendrá entonces la clave privada. Sin embargo, si Acme Co. migra a la nube con un proveedor que utiliza SSL/TLS sin clave, la clave privada puede permanecer en el servidor propio que Acme Co. controla, como en la implementación de TLS sin nube.

¿Cómo funciona SSL sin clave?

SSL sin clave se basa en el hecho de que la clave privada solo se usa una vez durante el protocolo de enlace de TLS que se produce al principio de una sesión de comunicación TLS. SSL sin clave funciona dividiendo los pasos del protocolo de enlace TLS geográficamente. El proveedor de soluciones en la nube que ofrece SSL sin clave traslada la parte del proceso en la que se usa la clave privada a otro servidor, normalmente uno que el cliente mantiene en sus propias instalaciones.

Cuando en el protocolo de enlace se necesita la clave privada para firmar y desencriptar datos, el servidor del proveedor reenvía los datos necesarios al servidor con la clave privada del cliente. La clave privada firma o desencripta los datos en el servidor del cliente y el servidor del cliente los envía de nuevo al servidor del proveedor, y entonces el protocolo de enlace TLS continúa con normalidad.

SSL sin clave solo es "sin clave" desde el punto de vista del proveedor de soluciones en la nube, ya que nunca ve la clave privada del cliente, que es quien la mantiene y la usa. Mientras tanto, el cliente continúa utilizando la clave pública de forma normal.

¿Cómo funciona el SSL sin clave con un protocolo de enlace TLS de intercambio de claves RSA?

En un protocolo de enlace RSA, los pasos en un protocolo de enlace TLS son los siguientes:

1. El cliente envía al servidor un mensaje "hola" de texto sin formato que incluye la versión del protocolo que desea utilizar, una lista de conjuntos de cifrado compatibles y una breve cadena de datos aleatorios denominada "cadena aleatoria del cliente".
2. El servidor responde (en texto sin formato) con su certificado SSL, su conjunto de cifrado de preferencia y una breve cadena diferente de datos aleatorios, denominada"cadena aleatoria del servidor".
3. El cliente crea otro conjunto de datos aleatorios, llamado "secreto premaster". Tomando la clave pública del certificado SSL del servidor, el cliente encripta el secreto premaster y lo envía al servidor; solo alguien con la clave privada puede desencriptar el secreto premaster.
4. El servidor desencripta el secreto premaster. ¡Como ves, este el único momento en el que se usa la clave privada!
5. Ahora tanto el cliente como el servidor tienen el valor aleatorio del cliente, el valor aleatorio del servidor y el secreto premaster. De manera independiente, combinan los tres datos para obtener las claves de sesión. Ambos deben obtener el mismo resultado y todas las comunicaciones posteriores durante la sesión se encriptan con esas nuevas claves de sesión.

SSL sin clave entra en juego en el paso 4. Con SSL sin clave, en lugar de desencriptar por sí mismo el secreto premaster, el proveedor de soluciones en la nube lo envía encriptado a través de un canal seguro a un servidor alojado o controlado por el cliente. La clave privada del cliente desencripta el secreto premaster y luego este se envía nuevamente al proveedor de soluciones en la nube. El servidor del proveedor de soluciones en la nube lo utiliza para derivar las claves de sesión y luego las comunicaciones mediante TLS continúan con normalidad.

¿Cómo funciona el SSL sin clave con el intercambio de claves Diffie-Hellman efímero?

El protocolo de enlace Diffie-Hellman efímero (DHE, por sus siglas en inglés) es "efímero" porque cada clave se usa una sola vez. Las claves de sesión se generan utilizando el algoritmo Diffie-Hellman, una manera de intercambiar claves a través de un canal no seguro. Con este tipo de protocolo de enlace TLS, el proceso de autenticación de claves privadas se separa de la generación de claves de sesión.

La diferencia principal entre el protocolo de enlace DHE y el RSA, además de los algoritmos usados, es la manera de generar el secreto premaster. En el protocolo de enlace RSA, el secreto premaster se forma con datos aleatorios generados por el cliente; en el protocolo DHE, el cliente y el servidor utilizan parámetros previamente acordados para calcular el mismo secreto premaster separadamente.

1. Al igual que en un protocolo de enlace RSA, el cliente envía la versión del protocolo que desea utilizar, una lista de los conjuntos de cifrado compatibles y la cadena aleatoria del cliente.
2. El servidor responde con la suite de cifrado de su elección, un valor aleatorio del servidor y su certificado SSL. Aquí empieza a diferenciarse el protocolo de enlace DHE del RSA: el servidor también envía su parámetro Diffie-Hellman (DH), que se usará para calcular el secreto premaster. También incluye un firma digital para la autenticación. Este es el único momento en el que se usa la clave privada y se autentica así la identidad del servidor.
3. El cliente verifica la firma digital del servidor y autentica el certificado SSL. Entonces responde con su parámetro DH.
4. Usando el parámetro DH del cliente y del servidor, ambas partes calculan por separado el secreto premaster.
5. Luego combinan el secreto premaster con el valor aleatorio del cliente y el valor aleatorio del servidor para obtener las claves de sesión.

La clave privada se usa solamente en el paso 2, precisamente cuando SSL sin clave realiza su función. En ese momento, el proveedor de SSL/TLS envía el valor aleatorio del cliente, el valor aleatorio del servidor y el parámetro DH al servidor controlado por el cliente que tiene la clave privada. Esta información se usa para generar la firma digital del servidor y se envía al proveedor en la nube, que la envía a su vez al cliente. El cliente puede verificar esta firma con la clave pública y continúa el protocolo de enlace. De esta manera, el proveedor de servicios en la nube no entra en contacto con la clave privada.

Los protocolos de enlace Diffie-Hellman efímeros, aunque pueden tardar algo más que los protocolos RSA, tienen la ventaja que se conoce como confidencialidad directa. Como la clave privada se utiliza solamente para la autenticación, un atacante en ruta no puede usarla para descubrir ninguna clave de sesión concreta.

¿Qué es una clave de sesión?

Una clave de sesión es una clave simétrica usada por las dos partes de una comunicación segura a través de TLS, después de que se haya realizado el protocolo de enlace TLS. Una vez que ambas partes han acordado un conjunto de claves de sesión, ya no hay necesidad de utilizar las claves públicas y privadas. TLS genera diferentes claves de sesión para cada una de las sesiones.

¿Qué es la confidencialidad directa? ¿Qué es la confidencialidad directa total?

La confidencialidad directa garantiza que los datos encriptados permanezcan encriptados, incluso si se expone la clave privada. También se conoce como "confidencialidad directa total". La confidencialidad directa es posible si se usa una clave de sesión exclusiva para cada sesión de comunicación, siempre y cuando la clave de sesión se genere separadamente de la clave privada. Si se pone en riesgo una clave de sesión exclusiva, el atacante en ruta solamente puede desencriptar esa sesión; las otras sesiones se mantendrán encriptadas.

En un protocolo configurado con confidencialidad directa, la clave privada se usa para la autenticación en el proceso inicial del protocolo de enlace y no se usa para otra cosa. El protocolo de enlace Diffie-Hellman efímero genera claves de sesión separadamente de la clave privada y por ello tiene confidencialidad directa.

Por el contrario, en el protocolo RSA no hay confidencialidad directa; si la clave privada se pone en riesgo, un atacante en ruta podría determinar las claves de sesión de conversaciones anteriores, porque puede desencriptar el secreto premaster, y los valores aleatorios de cliente y del servidor están en texto no cifrado. Combinando los tres, el atacante en ruta puede derivar cualquier clave de sesión.

¿Cómo implementa Cloudflare el SSL sin clave?

Cloudflare fue el primer proveedor de soluciones en la nube que lanzó SSL sin clave, permitiendo que las empresas con restricciones rigurosas de seguridad, como los bancos, migraran a la nube. Cloudflare es compatible con los protocolos de enlace RSA y Diffie-Hellman, por lo que las empresas pueden incorporar la confidencialidad directa y protegerse frente a la posibilidad de que un atacante en ruta desencripte sus datos robando su clave privada.

Todas las comunicaciones entre los servidores de Cloudflare y los servidores de claves privadas se realizan mediante un canal seguro y encriptado. Además, Cloudflare ha comprobado que el uso de SSL sin clave apenas afecta al rendimiento, a pesar de los recorridos adicionales al servidor de claves privadas.

Para más detalles técnicos acerca del funcionamiento de SSL sin clave, consulta esta publicación del blog. Para más información acerca del SSL sin clave de Cloudflare, conoce los detalles de nuestro servicio de SSL sin clave.