Secreto directo perfecto. ¿Lo que es? – Certificados SSL –

¿Qué es FS?

Forward Secrecy (también conocido como Perfect Forward Secrecy) es un atributo de los mecanismos específicos de intercambio de claves en los protocolos de seguridad SSL/TLS que implica la independencia de la clave de sesión generada durante el establecimiento seguro de la sesión del conjunto de claves públicas y privadas de largo plazo. y las claves de sesión utilizadas en sesiones anteriores.

La misión del intercambio de claves es garantizar que dos partes acuerden una clave de sesión según las configuraciones de seguridad disponibles para ambos participantes de la negociación segura y que nadie más lo sepa.

Para una mejor comprensión, revisemos primero el acuerdo de claves no FS basándonos en el ejemplo del mecanismo de intercambio de claves RSA. El intercambio de claves RSA es compatible con casi cualquier aplicación que utilice el protocolo SSL/TLS.

Así es como funciona: el servidor envía su certificado, el cliente elige una clave de sesión aleatoria, la cifra con la clave pública del servidor obtenida del certificado y la envía de vuelta al servidor. La clave de sesión sólo se puede descifrar con la clave Privada del servidor que corresponde a la clave Pública, creando así la sesión segura.

De tal manera, el servidor establece cientos de miles de sesiones utilizando el mismo par de claves, creando un vínculo entre las claves a largo plazo y la clave de sesión para cada sesión única.

Como vemos, el secreto de la clave de sesión depende únicamente del secreto de la clave privada del servidor, lo que lleva a la conclusión obvia: ¿qué pasa si alguien consigue la clave privada?

Si la clave privada se filtra o se ve comprometida, un adversario puede retroceder en el tiempo y descifrar todo el tráfico previamente rastreado (grabado) cifrado utilizando el mismo par de claves a largo plazo y robar la información confidencial transmitida a través de los canales de la red.

See also  Creador de logotipos verdes: cree un logotipo con ideas de diseño de logotipos verdes

Una analogía simple, como si alguien irrumpiera en tu casa, podría ver no solo lo que hay allí ahora mismo, sino también saber todo del pasado: todas las personas que solían vivir allí, todas las conversaciones que solían tener. lugar en la casa o incluso el nombre de tu gato.

Al implementar los mecanismos de intercambio que proporcionan Forward Secrecy, aunque alguien irrumpa en una casa, seguirá sin saber qué estaba sucediendo antes de llegar allí.

Beneficios/Inconvenientes

Los mecanismos que proporcionan FS utilizan como material de claves el intercambio de claves Diffie-Hellman (DH), precisamente su modalidad Efímera. (Open Web Application Security Project) ofrece la siguiente definición de claves efímeras:

Las claves efímeras son claves temporales que se utilizan para una instancia de ejecución de un protocolo y luego se desechan. Una clave efímera tiene la ventaja de proporcionar confidencialidad directa, lo que significa que un compromiso de la clave de firma (estática) a largo plazo del sitio o servicio no facilita el descifrado de mensajes pasados ​​porque la clave era temporal y se descartó (una vez que finalizó la sesión).

En otras palabras, la clave de sesión generada a partir de los parámetros DH negociados es única para cada sesión individual, no depende de las claves a largo plazo del servidor (solo se utilizan para fines de autenticación del servidor) y se borrará una vez finalizada la sesión. . Evidentemente, esto aumenta drásticamente la protección del tráfico cifrado.

Sólo el Diffie-Hellman Ephemeral (DHE) y su versión más ligera basada en mecanismos de intercambio de claves de Curvas Elípticas (ECDHE) proporcionan Forward Secrecy.

Después de todo, tanto DHE como ECDHE degradan el rendimiento del sitio web (es decir, la velocidad de carga de la página) cuando se usan con claves RSA de largo plazo, ya que ambos implican una aritmética pesada que aumenta significativamente la carga de la CPU. Sin embargo, cuando se utiliza con claves a largo plazo ECDSA (algoritmo de firma digital de curva elíptica), el archivo . Por ahora, las claves EC aún no cuentan con un soporte tan amplio. A pesar de eso, ya puede obtener de nosotros el certificado firmado con la clave EC. No dudes en consultar más detalles.

See also  Jerga del inversor de dominios: lo que necesita saber - Blog de

El uso de conjuntos de cifrado que proporcionan intercambios de claves solo con FS puede causar algunas incompatibilidades con , pero ¿no es un costo razonable para dicha mejora de seguridad?

Cabe mencionar que se debe prestar especial atención al habilitar el soporte de las suites de cifrado que implican intercambio de claves DHE ya que son el principal vector de la nueva vulnerabilidad en el protocolo TLS descubierta por el grupo de investigadores que nos trajo el . El nuevo ataque se llama . DHE con grupo DH débil y conjuntos de cifrado DHE_EXPORT se ven afectados.

Para mitigar el ataque, se debe desactivar el soporte de los conjuntos de cifrado DHE-EXPORT. En cuanto a los cifrados DHE, se recomienda utilizar en su lugar. El tamaño de la clave DH en un grupo de cifrado DH personalizado debe aumentarse para que coincida con la longitud recomendada de la clave a largo plazo (el estándar actual es de 2048 bits).

Algunos servidores no tienen una opción para configurar grupos DH personalizados o cambiar el tamaño de la clave DH; por lo tanto, se debe desactivar la compatibilidad con conjuntos de cifrado DHE. Como alternativa, se debe utilizar el ECDHE. El intercambio de claves ECDHE es ligeramente más rápido en comparación con DHE y es ampliamente compatible con la mayoría de los navegadores web.

Otro inconveniente es que, debido al desconocimiento de los administradores del servidor, el secreto de reenvío puede romperse fácilmente. No basta con habilitar el soporte de las suites de cifrado con ciertos mecanismos de intercambio de claves FS en el servidor, sino priorizar su uso por parte del servidor en primer lugar y en todo momento.

See also  Cómo crear un enlace simbólico en cPanel - Hosting -

Otra forma de alterar el secreto de reenvío es configurar el servidor para que utilice ID de sesión de larga duración o tickets de sesión, que se utilizan para la reanudación de la sesión.

Ivan Ristic, director de ingeniería de la firma de seguridad en la nube, define los siguientes vectores de ataque en su escrito dedicado a Forward Secrecy:

“Los mecanismos de gestión de sesiones del lado del servidor también podrían afectar el secreto directo. Por motivos de rendimiento, las claves de sesión pueden conservarse durante muchas horas (o más) después de finalizar la conversación.

Además, existe un mecanismo de gestión de sesiones alternativo llamado tickets de sesión, que utiliza claves de cifrado separadas que rara vez se rotan (posiblemente nunca en casos extremos). A menos que comprenda muy bien la implementación de sus tickets de sesión, es mejor desactivar esta función para garantizar que no comprometa el secreto directo”.

Los métodos para comprobar si el servidor utiliza el intercambio de claves que proporciona Forward Secrecy se describen en .

Loading Facebook Comments ...
Loading Disqus Comments ...