¿Es TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 un conjunto de cifrado seguro para usar?

10

¿TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 es un conjunto de cifrado seguro para usar en una conexión TLS 1.2 a un servidor Tomcat? ¿Cuáles son las debilidades potenciales o mejores alternativas? Estoy buscando un cifrado soportado por Java 8.

    
pregunta JRA_TLL 14.11.2014 - 15:14
fuente

2 respuestas

18

Los nombres de los conjuntos de cifrado TLS están estructurados de tal manera que puede indicar qué algoritmos y tamaños de clave se utilizan para cada parte del protocolo de enlace y la sesión cifrada. Analicemos esto y veamos si hay mejoras que podamos hacer:

  • TLS : esto no significa nada en sí mismo, pero me permite mencionar que TLS 1.2 es la última versión de TLS y no tiene vulnerabilidades conocidas.
  • ECDHE - Curva elíptica Diffie-Hellman con teclas efímeras. Este es el método de intercambio de claves. Los intercambios de claves Diffie-Hellman que usan claves efímeras (generadas por sesión) brindan un secreto hacia adelante, lo que significa que la sesión no se puede descifrar después del hecho, incluso si se conoce la clave privada del servidor. La criptografía de curva elíptica proporciona una resistencia equivalente a la criptografía de clave pública tradicional y requiere tamaños de clave más pequeños, lo que puede mejorar el rendimiento. Además, sirven como una cobertura contra una ruptura en RSA.
  • RSA : el certificado del servidor debe contener una clave pública RSA, y la clave privada correspondiente debe usarse para firmar los parámetros ECDHE. Esto es lo que proporciona la autenticación del servidor. La alternativa sería ECDSA, otro algoritmo de curva elíptica, pero puede estar restringido por los tipos de certificados que firmará su CA.
  • AES_128 - El cifrado simétrico de cifrado es AES con claves de 128 bits. Esto es razonablemente rápido y no está roto (a menos que piense que la NSA tiene AES de puerta trasera, un tema para otro momento). Aparte de AES_256 (que puede ser demasiado costoso en cuanto al rendimiento), es la mejor opción de los cifrados simétricos definidos en RFC 5246 , los otros son RC4 (que tiene algunas debilidades conocidas y puede romperse relativamente pronto) y 3DES_EDE (que solo tiene una resistencia de bits práctica de 108 a 112, dependiendo de su fuente).
  • CBC - Modo de encadenamiento de bloques de cifrado. Aquí es donde probablemente pueda mejorar su elección. El modo CBC es una forma de emplear un cifrado de bloque para cifrar una pieza de datos de longitud variable, y ha sido la fuente de problemas de TLS en el pasado: BEAST, Lucky-Thirteen y POODLE fueron ataques en TLS en modo CBC. Una mejor opción para el rendimiento y la seguridad es AES_128_GCM, que es uno de los nuevos cifrados AEAD introducidos en TLS 1.2 y tiene buenas características de rendimiento y seguridad.
  • SHA256 : esta es la función hash que subyace a la función del Código de autenticación de mensaje (MAC) del conjunto de cifrado TLS. Esto es lo que garantiza que cada mensaje no haya sido manipulado en tránsito. SHA256 es una excelente opción, y es el algoritmo hash predeterminado para varias partes de TLS 1.2. Estoy bastante seguro de que el uso de SHA-1 estaría bien aquí, ya que la ventana para explotación es mucho más pequeña que, por ejemplo, La firma del certificado. Para empezar, los conjuntos de cifrado AEAD se autentican, por lo que este paso MAC adicional no es necesario o implementado.

Esencialmente, ha elegido un buen conjunto de cifrado que no tiene ningún problema práctico por ahora, pero es posible que desee cambiar a un conjunto de cifrado AEAD (AES-GCM o ChaCha20-Poly1305 de Google) para mejorar el rendimiento y la protección contra futuros CBC. Vulnerabilidades relacionadas.

    
respondido por el bonsaiviking 14.11.2014 - 16:40
fuente
7

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 es tan "seguro" como puede ser cualquier conjunto de cifrado: no hay ninguna debilidad de protocolo conocida relacionada con TLS 1.2 con ese conjunto de cifrado. Cualquier implementación en particular puede, por supuesto, dañar cosas e introducir debilidades por su propia cuenta. También puede pisotear su propia seguridad, por ejemplo, al no proteger adecuadamente el almacenamiento de la clave RSA de su servidor; o usar la generación de pares de claves débiles para esa clave RSA; o desactivación de la validación de certificados en el cliente; o cualquier otra de las miles de acciones estúpidas que se pueden hacer si no cuida .

    
respondido por el Thomas Pornin 14.11.2014 - 15:24
fuente

Lea otras preguntas en las etiquetas