¿Cuál es el impacto de eliminar TLS_RSA_WITH_RC4_128_SHA del conjunto de cifrado de mi servidor?

El conjunto de cifrado global determina la compatibilidad, no la presencia o ausencia de un cifrado. Deberás probar diferentes configuraciones para averiguarlo.

Si ya estás haciendo prueba del servidor SSL Lab , ese es tu mejor recurso para Determinando el impacto del cambio. Cuando dices que eres

  

configurar algunos certificados nuevos y equilibradores de carga

que sugiere que puedes experimentar con cambios en estos sistemas porque todavía no están en uso en producción. Así que elimine TLS_RSA_WITH_RC4_128_SHA y vuelva a ejecutar la Prueba del servidor SSL y preste atención a la sección de los resultados de Simulación de reconocimiento. Eso le dirá qué clientes tendrán problemas, como la siguiente configuración donde IE 6 en XP no puede trabajar con mi conjunto de cifrado:

Ahora, ese servidor tiene RC4 completamente desactivado, y los dos únicos clientes que son incompatibles son IE 6 en XP y Java 6u45, pero Java falló porque" el cliente no admite los parámetros DH > 1024 bits ", no" protocolo o conjunto de cifrado no coinciden " que es lo que esperaría para ver si la falta de RC4 era el problema.

SSL Labs es una herramienta increíble porque le permite jugar con diferentes configuraciones para obtener el equilibrio de seguridad y compatibilidad que necesita. Según mis resultados, sospecho que puede arreglárselas sin RC4 ( DH incrementado de mi servidor Los requisitos son relativamente nuevos para Apache , por ejemplo). Pero este es realmente un caso de YMMV . Es posible que desee utilizar cipherli.st para guiarlo en la prueba de nuevas configuraciones.

las suites de cifrado tienen propiedades de seguridad bien entendidas como TLS RSA WITH RC4 128 SHA que usa RSA para el intercambio de claves, RC4 de 128 bits para encriptación masiva y SHA para hash.

por otro lado:

El ataque BEAST es una antigua debilidad académica que recientemente se ha demostrado que es aplicable en la práctica. Requiere que el atacante espíe el enlace y ejecute un código hostil en el cliente (y ese código debe comunicarse con el sistema de espionaje externo); Los autores de BEAST han logrado ejecutarlo cuando el código interno hostil usa Java o Javascript. La solución genérica es cambiar a TLS 1.1 o 1.2, que son inmunes. Además, esto solo concierne a los cifrados de bloque en el modo CBC.

Si el ataque BEAST puede aplicarse a sus usuarios, no lo elimine, pero es mejor que use otro conjunto de cifrado fuerte porque:

RC4 como un cifrado de flujo es inmune al ataque BEAST. Por lo tanto, RC4 fue ampliamente utilizado como una forma de mitigar el ataque BEAST en el lado del servidor. Sin embargo, en 2013, los investigadores encontraron más debilidades en RC4. A partir de entonces ya no se recomendó habilitar RC4 en el lado del servidor.

AIUI: si quieres admitir IE 6, entonces básicamente debes admitir al menos uno de TLS_RSA_WITH_RC4_128_SHA o TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Ambos tienen sus problemas. RC4 tiene problemas graves de sesgo en la secuencia clave. CBC ha sido golpeado por el relleno y los ataques relacionados con IV (BEAST, POODLE, etc.).

El consenso general en este momento parece ser que si necesita admitir IE 6, entonces TLS_RSA_WITH_3DES_EDE_CBC_SHA es un mal menor que TLS_RSA_WITH_RC4_128_SHA