Por qué con las claves de TLS el mayor tamaño no siempre es una ventaja | Fastly

A la hora de configurar el certificado TLS, hay que tomar decisiones complicadas. Por ejemplo, la elección del tamaño (número de bits) de las claves de cifrado que se utilizan en los certificados del servidor. A simple vista, puede parecer prudente elegir una clave RSA de 4096 bits en lugar de la típica de 2048 bits; sobre todo cuando hay que proteger la información que se va a cifrar durante muchos años. Examinemos la función del certificado de TLS y las operaciones de cifrado que utiliza el TLS para poder entender por qué esta decisión no es tan sencilla como parece.

En todas las versiones del protocolo TLS, el certificado juega un papel muy concreto: sirve para validar el nombre del host del sitio web y para crear una clave de sesión con la que proteger los datos que están en tránsito. Por lo tanto, la solidez de la clave de sesión tiene tanta importancia como la clave del certificado que protege tus datos, o más incluso.

La solidez viene determinada por el «conjunto de cifrado». Se trata de un parámetro que acuerdan el navegador y el servidor web al establecerse la conexión TLS, y que define el método con el que configurar la clave de sesión. Además, la confidencialidad directa (FS) es una propiedad de los mecanismos modernos de acuerdo de claves que garantiza que la clave privada del certificado no pueda usarse para recuperar las claves de sesión. Cuando se aplica uno de estos mecanismos que proporciona la FS, las claves no seguras que estén representadas en el certificado no podrán usarse para recrear claves de sesión antiguas. Aunque se descifre la clave del certificado, esta no correrá ningún riesgo, incluso si los datos de TLS cifrados llevaran almacenados mucho tiempo. En resumen, no hay vulnerabilidad que permita al atacante descifrar el tráfico TLS enviado antes del ataque. 

Por defecto, la CDN de Fastly está configurada para usar la FS cuando el navegador la admite. Para ello, los clientes pueden precisar que las conexiones usen TLS 1.3 (la última versión del protocolo, que solo permite los conjuntos de cifrado de FS) o pedir una configuración TLS personalizada.

El NIST publica de forma periódica una serie de recomendaciones para el uso de los algoritmos de cifrado que definen en bits de seguridad la protección relativa de contenido que proporcionan los diferentes tipos de algoritmos. Dicho organismo recomienda proteger los datos con claves con una solidez mínima de 112 bits de seguridad hasta 2030; y, de ahí en adelante, con 128 bits de seguridad. Esos 112 bits de seguridad se pueden conseguir con una clave RSA de 2048 bits. Los certificados TLS tienen una validez máxima de un año. Es decir, la longitud de la clave RSA de 2048 bits cumple con la recomendación del NIST hasta finales de esta década. Además, las normas de seguridad de datos para el sector de tarjetas de pago (PCI DSS) exigen usar un cifrado «sólido». ¿Qué significa? A día de hoy, claves RSA de 2048 bits o claves ECC de 224 bits (o más).

Aunque una clave RSA mayor de 4096 bits no sea necesaria, quizá te preguntes qué podría haber de malo en decantarse por una de mayor tamaño. La respuesta es que el rendimiento se ve afectado. Cuando las claves son más largas, se necesita más tiempo de computación tanto en el lado del servidor como en el del cliente. Recientemente llevamos a cabo unas pruebas en los servidores de Fastly, y comprobamos que las operaciones de verificación de una clave RSA de 4096 bits tardaron cuatro veces más en ejecutarse que una de 2048 bits. Si a eso le añadimos los datos adicionales que se tienen que transmitir al cliente cuando se usan un certificado intermedio y un servidor de RSA de 4096 bits, los efectos sobre el rendimiento son considerables. Por eso, si cada año escoges una clave más pequeña al renovar el certificado, puedes mejorar el rendimiento hasta que llegue el momento de utilizar claves más robustas.

Una solución todavía mejor es pasarte a los certificados ECDSA. Su soporte matemático es diferente al de los certificados RSA y genera tamaños de clave mucho más pequeños cuyos niveles de protección brillan por su solidez: una clave ECDSA de 256 bits proporciona 128 bits de seguridad. O sea, lo mismo que una clave RSA de 3072 bits. Ahora que Fastly admite los certificados ECDSA, ya no tendrás que sacrificar el rendimiento por la mejora de seguridad que ofrecen las claves RSA de 4096 bits. Si te preocupa que ECDSA sea un algoritmo criptográfico relativamente nuevo (de la década de 1990), quizás te interese echar un vistazo al ciberespacio: cualquier visita que hagas a Google.com te devuelve ahora un certificado ECDSA.

En resumen, la configuración de tu servidor web es y será un aspecto esencial para proteger los datos que se transmiten a través de TLS. Pero, para ello, debes hacer algunas concesiones, es decir, sacrificar la seguridad en beneficio de la compatibilidad porque es posible que algunos programas cliente más antiguos no admitan TLS 1.3. De hecho, Mozilla suele recomendar configuraciones que tienen en cuenta estos sacrificios o concesiones. En cuanto a los certificados TLS para servidores, las claves RSA de 2048 bits o las ECDSA de 256 bits ofrecen actualmente la mejor combinación de seguridad y rendimiento. Si, a pesar de todo, te planteas utilizar una clave más larga, te recomiendo que antes consideres qué función va a desempeñar el certificado y qué efectos podría tener esa decisión en el rendimiento.