¿Cómo funciona el SSL sin clave? | Secreto hacia adelante

El SSL sin clave hace posible que las organizaciones que no pueden compartir sus claves privadas se trasladen a la nube y, al mismo tiempo, mantengan la encriptación SSL/TLS.

Metas de aprendizaje

Después de leer este artículo podrás:

  • Explicar los pasos en un protocolo de enlace TLS y la diferencia entre una clave de sesión y una clave privada
  • Comprender cómo el SSL sin clave separa la parte del protocolo de enlace de TLS mediante una clave privada del resto del protocolo de enlace
  • Conocer la diferencia entre los protocolos de enlace RSA y Diffie-Hellman
  • Comprender qué es el secreto hacia adelante

Contenido relacionado


Want to keep learning?

Subscribe to theNET, Cloudflare's monthly recap of the Internet's most popular insights!

Revisa la política de privacidad de Cloudflare para saber más sobre cómo Cloudflare gestiona tus datos personales.

Copiar el enlace del artículo

¿Qué es el SSL sin clave?

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 generar una clave de sesión, el proveedor de la nube obtiene las claves de sesión de la empresa por medio de un canal seguro y las usa para mantener la encriptación. 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 un SSL. 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. El SSL sin clave funciona al separar los pasos del protocolo de enlace TLS. 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 desencriptar o encriptar datos, el servidor del proveedor envía los datos necesarios al servidor de la clave privada del cliente. La clave privada encripta o desencripta los datos en el servidor del cliente y envía los datos de regreso al servidor del proveedor, y 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.

¿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.

¿Cuáles son los pasos para generar claves de sesión?

Esto depende del tipo de algoritmo de intercambio de claves que se utilice en el protocolo de enlace TLS. Los dos principales son los algoritmos de intercambio de claves RSA y Diffie-Hellman.

El intercambio de claves RSA

En un protocolo de enlace RSA, los pasos en un protocolo de enlace TLS para crear claves de sesión 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 estas tres entradas para generar las claves de sesión. Ambos deberían obtener el mismo resultado, y se encriptan las comunicaciones subsiguientes durante la sesión con estas nuevas claves.
Protocolo de enlace SSL (RSA) sin SSL sin clave

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.

Protocolo de enlace SSL (RSA) sin clave de Cloudflare

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. Asimismo, encripta la cadena aleatoria del cliente, del servidor y el parámetro DH con la clave privada del servidor. 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 desencripta el mensaje del servidor con la clave pública 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.
Protocolo de enlace SSL (Diffie-Hellman) sin SSL sin clave

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 encripta con la clave privada y envía de regreso de forma encriptada al proveedor en la nube, quien la reenvía al cliente. El cliente puede desencriptar estos datos con la clave pública, y el protocolo de enlace continúa. De este modo, el proveedor en la nube no requiere acceder a la clave privada.

SSL sin clave (Diffie-Hellman) de Cloudflare

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 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 establecido para un secreto hacia adelante, se utiliza la clave privada para autenticación durante el proceso de protocolo de enlace inicial, de cualquier otro modo no se usa para encriptación. 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 desencriptar claves de sesión para conversaciones anteriores, ya que puede desencriptar 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 soporta tanto el protocolo de enlace RSA como el Diffie-Hellman para que las empresas puedan incorporar el secreto hacia adelante a través de Diffie-Hellman y protegerse contra la posibilidad de que un atacante desencripte sus datos luego de robar la 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.