¿Qué cifrados SSL / TLS pueden considerarse seguros?

Las suites de cifrado con un " NULL " no ofrecen cifrado de datos, solo verificación de integridad. Esto significa "no seguro" para la mayoría de los usos.

Las suites de cifrado con " EXPORT " son, por diseño, débiles. Se están encriptados, pero solo con claves lo suficientemente pequeñas como para ser crackeadas incluso con hardware amateur (por ejemplo, una PC doméstica básica: encriptación simétrica basada en claves de 40 bits). Estas suites se definieron para cumplir con las reglas de exportación de los EE. UU. Sobre sistemas criptográficos, reglas que eran bastante estrictas antes de 2000. Hoy en día, estas restricciones se han eliminado y no tiene mucho sentido apoyar las suites de cifrado " EXPORT ".

Las suites de cifrado con " DES " (no " 3DES ") dependen del cifrado simétrico en DES , un antiguo cifrado de bloque que utiliza una clave de 56 bits ( técnicamente , utiliza una clave de 64 bits, pero ignora 8 de esos bits, por lo que el tamaño efectivo de la clave es de 56 bits). Una clave de 56 bits es crackeable, aunque no en cinco minutos con una PC. Deep crack fue una máquina de propósito especial construida en 1998 por aproximadamente 250,000 $, y podría romper una clave DES de 56 bits dentro de 4.5 días en promedio. La tecnología ha progresado, y esto puede reproducirse con unas cuantas docenas de FPGA . Todavía no es un hardware de Walmart, pero es asequible para muchas personas.

Todas las demás suites de cifrado compatibles con OpenSSL no son débiles; Si tiene un problema con ellos, no será debido a una debilidad criptográfica en los algoritmos. Es posible que desee evitar las suites de cifrado que cuentan con " MD5 ", no debido a una debilidad real conocida, sino para las relaciones públicas. MD5 , como función hash, está "dañada" porque podemos encontrar muchas colisiones para esa función de manera eficiente. Esto no es un problema para MD5 ya que se usa en SSL; sin embargo, eso es suficiente para que MD5 tenga una mala reputación, y es mejor evitarlo.

Tenga en cuenta que la suite de cifrado no impone ninguna medida en el tamaño de la clave del servidor (la clave pública en el certificado del servidor), que debe ser lo suficientemente grande como para proporcionar una robustez adecuada (para RSA o DSS, vaya a 1024 bits como mínimo , Mejorando 1536 bits, pero no lo presione demasiado, porque la sobrecarga computacional aumenta considerablemente con el tamaño de la clave).

NIST , una organización federal de los EE. UU. que es tan aceptada y conocida como cualquier organización de seguridad puede ser, ha publicó algunas recomendaciones (consulte especialmente las tablas en las páginas 22 y 23); Esto es de 2005 pero sigue siendo válido hoy. Tenga en cuenta que NIST opera sobre una base "aprobada / no aprobada": no afirman de ninguna manera que los algoritmos que "no están aprobados" son débiles de ninguna manera; solo que ellos, como organización, no responden por ellos.

¿Ha leído SSL y TLS: Diseñando y construyendo sistemas seguros , por Eric Rescorla? Es el clásico aceptado sobre SSL, escrito por uno de los principales contribuyentes al grupo de trabajo de estándares IETF sobre SSL. Espero que pueda contener declaraciones adecuadas sobre la solidez de varios conjuntos de cifrado SSL.

Si eso no satisface tus necesidades, puedes ir a tu biblioteca amigable y revisar todos los libros de texto de criptografía y seguridad que tienen y leer las secciones escritas en SSL / TLS.

Básicamente, si está buscando una referencia para documentar hechos que todos los expertos en seguridad ya conocen, es posible que deba hacer un poco de trabajo por su cuenta para encontrar la mejor cita.

Algunas pequeñas adiciones a la respuesta de Thomas Pornin: mientras que el NIST SP800-52 sigue siendo oficial (aunque algo fuera de fecha) para TLS en general, para tamaños de clave específicamente es reemplazado por SP800-57: part1 cubre tamaños de clave y vidas en general, Revisado el año pasado 2012; part3 cubre algunas aplicaciones específicas, incluido el TLS emitido en 2010. En resumen, intentaron requerir RSA DSA y DH 2048 bits y ECC 224 bits en 2011, pero hubo demasiada respuesta por lo que ahora es 2014, ¡próximamente! (DSA a 2048 o 3072 bits está especificado por FIPS 186-3 en 2009, pero aún no veo mucha implementación. Incluso openssl lo hizo bastante torpemente). Www.CABforum.org coincide con RSA 2048 en 2014; Si bien no tiene que obtener su certificado de un CA "oficial", hacer una práctica "estándar" visiblemente menos que común tiende a ser tratado con escepticismo. FWIW NIST actualmente dice que la resistencia (Z_n 2048, ECC 224, simétrica 112) es "aceptable" hasta 2030, después de lo cual se requiere 3072/256/128; incluso si resultan equivocados, si vas con ellos tienes una excusa tan buena como la que puedes encontrar, y definitivamente tendrás mucha buena compañía. Por último, csrc.nist.gov es una mejor URL de inicio para la ciberseguridad (el NIST en conjunto hace muchas otras cosas).

Ponerse al día con las recomendaciones oficiales podría ser una tarea desalentadora para la mayoría de los usuarios.

La forma más rápida de obtener una lista actualizada de cifrados modernos es verificar periódicamente Generador de configuración SSL de Mozilla .

A partir de agosto de 2016, la lista (ordenada) es:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256

Más allá de simplemente aplicar estos cifrados, asegúrese de:

• establece la versión TLS a 1.2 (o superior)
• use parámetros DH personalizados (> = 3072bit)
• use una curva de 384 bits segura (como se define en safecurves.cr.yp.to ) .

Nota: todos estos cifrados son compatibles con el (próximo) TLS1.3.