Esta es la solución más exacta que encomtrarás compartir, pero primero mírala detenidamente y valora si es compatible a tu proyecto.
Los nombres de conjuntos de cifrado TLS están estructurados de tal manera que puede saber qué algoritmos y key los tamaños se utilizan para cada parte del protocolo de enlace y la sesión cifrada. Desglosemos este y veamos si hay alguna mejora 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 Efímero keys. Este es el key método de intercambio. Diffie-Hellman key intercambios que utilizan efímero (generado por sesión) keys proporcionar secreto hacia adelante, lo que significa que la sesión no se puede descifrar después del hecho, incluso si el servidor es privado key es conocida. La criptografía de curva elíptica proporciona una fuerza equivalente a la tradicional criptografía pública.key criptografía mientras requiere más pequeño key tamaños, lo que puede mejorar el rendimiento. Además, sirven como una apuesta de cobertura contra una ruptura en RSA.RSA– El certificado del servidor debe contener un RSA public key, y el privado correspondiente key debe utilizarse 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 es posible que esté restringido por los tipos de certificados que firmará su CA.AES_128– El cifrado de cifrado simétrico es AES con 128 bits keys. Esto es razonablemente rápido y no está roto (a menos que crea que la NSA ha hecho una puerta trasera a AES, un tema para otro momento). Aparte de AES_256 (que puede ser demasiado costoso en términos de 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 fuerza de bit práctica de 108 a 112, dependiendo de su fuente).CBC– Modo de encadenamiento de bloques de cifrado. Aquí es donde probablemente puedas mejorar tu 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 contra 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 en la característica del código de autenticación de mensajes (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 usar SHA-1 estaría bien aquí, ya que la ventana para la 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 ni se implementa.
Esencialmente, ha elegido un buen conjunto de cifrado que no tiene problemas prácticos 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 futuras vulnerabilidades relacionadas con CBC. .
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 es tan “seguro” como puede ser cualquier conjunto de cifrado: no se conoce ninguna debilidad de protocolo relacionada con TLS 1.2 con ese conjunto de cifrado. Cualquier particular implementación puede, por supuesto, estropear las cosas e introducir debilidades por sí solo. También puede pisotear su propia seguridad, por ejemplo, al no proteger adecuadamente el almacenamiento de su servidor RSA key; o usando débil key generación de pares para ese RSA key; o desactivar la validación de certificados en el cliente; o cualquier otra de un trillón de acciones estúpidas que son factibles si no lo haces Cuídate.
Hubo una actualización reciente en todos los cifrados CBC que podría hacerlos inseguros en la mayoría de las situaciones. Por lo tanto, probablemente debería volver a evaluar la seguridad de su servidor ejecutando una verificación. (Más información de SSLLabs)
En cuanto a qué usar, cfieber comentó correctamente, y sus mejores (y únicas) apuestas para Java 8 ahora son TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 y TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 dependiendo del tipo de certificado. (Tomado de aquí)
Reseñas y calificaciones del post
Si conservas algún reparo y capacidad de innovar nuestro post eres capaz de añadir un exégesis y con gusto lo interpretaremos.