¿Cómo funciona el SSL sin clave?

¿Qué es el SSL sin clave?

El SSL sin clave es un servicio para empresas que utilizan un proveedor de nubes para la encriptación de SSL. Por lo general, esto significa que el proveedor de nubes debe conocer la clave privada de la empresa, pero el SSL sin clave es una forma de eludir esto. Por razones regulatorias, muchas organizaciones no pueden compartir sus claves privadas. Con el SSL sin clave, estas organizaciones siguen teniendo la posibilidad de utilizar el TLS y aprovechar la nube, mientras mantienen sus claves seguras.

El SSL, denominado con mayor exactitud TLS, es un protocolo para autenticar y encriptar comunicaciones en una red. El SSL/TLS requiere el uso de las denominadas clave pública y clave privada; en el caso de una empresa que utiliza un protocolo para proteger el tráfico hacia y desde su sitio web (ver HTTPS), la clave privada permanece, por lo general, en posesión de la empresa. Sin embargo, cuando la empresa se muda a la nube y un proveedor proporciona una encriptación de TLS, el proveedor es quien tiene la clave privada.

Al remover la parte del protocolo de enlace vinculada a la clave privada del servidor del proveedor, la clave privada puede permanecer 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 cifrado. Por lo tanto, se continúa utilizando una clave privada, pero sin compartirla con nadie fuera de la empresa.

Por ejemplo, supongamos que Acme Co. implementa TLS. Almacenará de manera segura su clave privada en un servidor que posee y controla. Si Acme Co. se muda a la nube y utiliza un proveedor de servicios en la nube para un alojamiento web, entonces ese proveedor tendrá la clave privada. Sin embargo, si Acme Co. se muda a la nube con un proveedor que implementa SSL sin clave, la clave privada puede permanecer en el servidor propiedad y bajo el control de Acme Co., como en la implementación de SSL fuera de la nube.

¿Cómo funciona el SSL sin clave?

El SSL sin clave se basa en el hecho de que la clave privada se usa una única vez durante la implementación del protocolo de enlace TLS, y ese momento es al comienzo de la sesión de la comunicación TLS. SSL sin clave funciona dividiendo los pasos del protocolo de enlace TLS geográficamente. Un proveedor de nubes que ofrece SSL sin clave mueve la parte de la clave privada del proceso a otro servidor, por lo general, un servidor que el cliente posee en sus instalaciones.

Cuando se requiere la clave privada durante el protocolo de enlace para descifrar o encriptar datos, el servidor del proveedor envía los datos necesarios al servidor de la clave privada del cliente. La clave privada firma o descifra 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.

El SSL sin clave "no posee una clave" únicamente desde del punto de vista del proveedor de nubes ya que nunca ve la clave privada del cliente, pero aún así el cliente la posee y la utiliza. Por otra parte, se utiliza la clave pública en el extremo del cliente como es habitual.

¿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 de "hola" sin formato que incluye la versión del protocolo que desea utilizar, una lista de los conjuntos de cifrado compatibles y una cadena corta 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 cadena corta de datos aleatorios diferente denominada "cadena aleatoria del servidor".
3. El cliente crea otro conjunto de datos aleatorios llamado "secreto premaster". Al tomar 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. ¡Tenga en cuenta que este es el único momento en el que se utiliza la clave privada!
5. Ahora tanto el cliente como el servidor poseen la cadena aleatoria del cliente, 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 cifran con esas nuevas claves de sesión.

El SSL sin clave se utiliza en el paso 4. Con el SSL sin clave, en lugar de desencriptar el secreto premaster él mismo, el proveedor en la nube lo envía encriptado por medio de un canal seguro a un servidor alojado y controlado por el cliente. La clave privada del cliente desencripta el secreto premaster y, luego, ya desencriptado es enviado de regreso a la nube del proveedor. El servidor del proveedor en la nube utiliza esto para derivar las claves de sesión, y las comunicaciones TLS continúan con normalidad.

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

Un protocolo de enlace Diffie-Hellman efímero (DHE) ("efímero" ya que la misma clave nunca se utiliza dos veces) genera claves de sesión con el algoritmo Diffie-Hellman, una forma de intercambiar claves a través de un canal no seguro. Con este tipo de protocolo de enlace TLS, la autenticación de clave privada es un proceso independiente de la generación de la clave de sesión.

La principal diferencia entre el protocolo de enlace DHE y uno RSA, además de los algoritmos utilizados, es la forma en que se genera el secreto premaster. En un protocolo de enlace RSA, el secreto premaster se crea de datos aleatorizados generados por el cliente; en un protocolo de enlace DHE, el cliente y el servidor acuerdan parámetros para calcular el mismo secreto premaster por separado.

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 sus conjuntos de cifrado elegidos, una cadena aleatoria del servidor y su certificado SSL. Aquí el protocolo de enlace DHE comienza a diferenciarse del protocolo de enlace 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. Esta es la única instancia en la que se utiliza la clave privada, y esta autentica que el servidor sea quien dice ser.
3. El cliente verifica la firma digital del servidor y autentica el certificado SSL. Luego, responde con su parámetro DH.
4. Ambas partes calculan el secreto premaster de manera independiente con el parámetro DH del cliente y el parámetro DH del servidor.
5. Posteriormente, combinan el secreto premaster con la cadena aleatoria del cliente y del servidor para obtener las claves de sesión.

La clave privada solo se utiliza en el paso 2 y es donde el SSL sin clave cobra importancia. En este punto, el proveedor de SSL/TLS envía la cadena aleatoria del cliente, del servidor y el parámetro DH del servidor al servidor controlado por el cliente que posee 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 este modo, el proveedor en la nube no requiere acceder a la clave privada.

Los protocolos de enlace Diffie-Hellman efímeros, aunque requieren más tiempo que los protocolos de enlace RSA, tienen la ventaja del denominado secreto hacia adelante. Debido a que la clave privada solo se utiliza para la autenticación, un atacante no puede usarla para descubrir ninguna clave de sesión.

¿Qué es una clave de sesión?

Una clave de sesión es una clave simétrica utilizada por ambos extremos de una comunicación segura por TLS, después de que se completa el protocolo de enlace TLS. Luego de que ambos extremos acuerdan un conjunto de claves de sesión, ya no hay necesidad de utilizar claves públicas y privadas. El TLS genera claves de sesión diferentes para cada sesión única.

¿Qué es el secreto hacia adelante? ¿Qué es el secreto perfecto hacia adelante?

El secreto hacia adelante garantiza que los datos encriptados mantengan la encriptación, incluso si la clave privada queda expuesta. Esto también se conoce como "secreto perfecto hacia adelante". El secreto hacia adelante es posible, si se utiliza una clave de sesión única para cada sesión de comunicación y si la clave de sesión se genera de manera separada de la clave privada. Si una sola clave de sesión está en riesgo, entonces el atacante puede desencriptar esa sesión únicamente; todas las demás sesiones permanecerá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 de forma separada de la clave privada y, por lo tanto, posee un secreto hacia adelante.

En contraste, el RSA no cuenta con un secreto hacia adelante; si la clave privada está en riesgo, un atacante puede descifrar claves de sesión para conversaciones anteriores, ya que puede descifrar el secreto premaster, y la cadena aleatoria del cliente y del servidor están en texto sin formato. Al combinar estos tres, el atacante puede derivar cualquier clave de sesión.

¿Cómo implementa Cloudflare el SSL sin clave?

Cloudflare fue el primer proveedor en la nube en lanzar el SSL sin clave, permitiendo a las empresas, como bancos, enfrentar las estrictas restricciones de seguridad y mudarse 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 descifre sus datos robando su clave privada.

Todas las comunicaciones entre los servidores de Cloudflare y los servidores de clave privada se realizan en un canal encriptado y seguro. Además, Cloudflare ha notado que el SSL sin clave tiene un mínimo impacto en el rendimiento, a pesar de los viajes adicionales al servidor de clave privada.

Para obtener más detalles técnicos sobre cómo funciona el SSL sin clave, echa un vistazo a esta entrada del blog. Para más información sobre el SSL sin clave de Cloudflare, explora los detalles de nuestro servicio de SSL sin clave.