Pasé por varios documentos en línea, por ejemplo, Mejores prácticas de implementación de SSL y TLS , con respecto a la selección "correcta" de suites de cifrado para un sitio web. La imagen adjunta muestra mi selección de suites de cifrado con menor prioridad de arriba a abajo, por ejemplo. ECDHE-ECDSA-CHACHA20-POLY1305 tiene la más alta prioridad. A continuación, explico esta selección y me gustaría recibir sus comentarios.
Obtuve los cifrados con el siguiente comando, proporcionado por LibreSSL 2.4.1:
openssl ciphers -v | grep -i dhe | grep -i -e ecdsa -e rsa | grep -i -v camellia | grep -i -v rc4 | grep -i -v 3des | grep -i -v ChaCha20-Poly1305-Old
Mis razones para la selección:
- dhe: permite solo cifrados que admiten el secreto hacia adelante
- ecdsa / rsa: deshabilita los cifrados débiles DSA / DSS
- camelia: ¿No se ha probado tanto como AES? Patente!
- rc4: débil
- 3des: débil
- ChaCha20-Poly1305-Old: borrador de cifrado
A partir de entonces, clasifiqué los cifrados con seguridad en mente:
- Primero elegí los cifrados que soportan AEAD debido a, entre otros:
"Debe confiar principalmente en las suites AEAD ..." (las mejores prácticas de SSLLABS)
- Luego, los cifrados ECDSA se favorecen sobre RSA. RSA1024 es débil, RSA2048 está bien por ahora, pero RSA3072 y superior ponen demasiada carga en el servidor (IMHO).
- Se favorece ECDH. DH con 2048 Bit y superior es seguro por ahora. Pero, las vulnerabilidades son conocidas por menores longitudes de clave. Por otro lado, secp256r1 (NIST P-256), que es el ECC con mayor soporte, es inseguro según Bernstein (URL: safecurves.cr.yp.to). Además, secp256r1 viene de NIST! ¿Qué piensas? Utiliza DH con vulnerabilidades conocidas para longitudes de teclas cortas o ECDH con secp256r1 proveniente de NIST y siendo inseguro según Bernstein?
Después de hacer mi selección en función de la fortaleza del cifrado, asigné más prioridad en función del rendimiento .
- Primero, hice mi selección basada en el algoritmo de cifrado, asumiendo que tiene un mayor impacto en el rendimiento que el algoritmo hash elegido. ¿Tengo razón o no?
- Dado que las PC y las computadoras portátiles generalmente tienen más rendimiento que los dispositivos móviles, me concentro en los dispositivos móviles y elegí los cifrados basados en ChaCha20 primero, que se ejecutan en dispositivos móviles basados en ARM más rápido que AES debido a la falta de soporte AES-NI (URL : blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/). Las PC modernas, por otro lado, tienen soporte AES-NI y se ejecutan más rápido con AES.
- Las opciones adicionales (AES128 sobre AES256 y SHA1- > SHA256- > SHA384) son autoexplicativas. HMAC-SHA1 no representa un riesgo de AFAIK. ¿O me equivoco?
Por cierto, no me importan los problemas de conectividad con Windows XP y algunos otros sistemas antiguos. ECDSA y RSA estarán disponibles en mi servidor web simultáneamente. Nginx admite varios certificados a partir de la versión 1.11.0, mientras que Apache lo admite durante más tiempo. Voy a usar el limpiador LibreSSL, que ya tiene ChaCha20.
