Sé que el cifrado RC4 cuando se usa con SSL es vulnerable a ciertos ataques , que en el peor de los casos podrían resultar en el robo de tokens de autenticación. Pero RC4 también se recomienda como cifrado para mitigar el ataque BEAST.
¿Es una mejor decisión estratégica, deshabilitar RC4 y quizás ser vulnerable a BESTIA, o proteger contra BESTIA y proteger contra el ataque al que RC4 es vulnerable?
En cualquier caso, el cliente sugiere pero el servidor elige . En el lado del cliente, puede especificar que prefiera usar AES si es posible, pero si el cliente es compatible con RC4 y el servidor quiere para usar RC4, si es posible, entonces lo será RC4. Esto implica que realmente no puede "usar RC4 como último recurso" (a menos que el código del cliente haga algunos trucos, lo cual no creo que implementen los clientes SSL principales; es decir, no anunciando el soporte de RC4, a menos que se realice una conexión anterior los intentos con otras suites de cifrado han fallado).
Una forma de verlo es que SSL protegido con RC4 es mucho mejor que ningún SSL. Otra forma es que, independientemente de lo que haga en el cliente, el servidor no se puede abstraer; usted está confiando al servidor con sus datos confidenciales. La elección del conjunto de cifrado es responsabilidad del servidor, y si el servidor no aplica los conjuntos de cifrado apropiados (desde su punto de vista), tal vez no debería enviar los datos a un servidor tan descuidado ...
Las debilidades conocidas de AES-CBC (el ataque BEAST) ya no funcionan si su cliente (navegador web) está actualizado (¡y realmente debería hacerlo!). Las debilidades conocidas de RC4 no parecen funcionar en un contexto web (debido a que la explotación de debilidades requiere millones de conexiones, y eso lleva tiempo; además, los primeros cientos de bytes de cada solicitud contienen encabezados HTTP que En su mayoría son poco interesantes para el atacante). Por lo tanto, se puede decir que: RC4 o no RC4, que es no la pregunta . Ya sea que deshabilites o habilites RC4, es muy poco probable que sea la mayor vulnerabilidad de seguridad, o incluso una vulnerabilidad importante .
Sin embargo, puede tener sentido deshabilitar RC4, o deshabilitar AES-CBC, para cumplir con algunas regulaciones inflexibles, o aumentar alguna "marca de seguridad" (muy artificial) que algunos auditores parecen muy aficionados, por ejemplo. razones que tienen más que ver con la psicología que con la criptografía.
La vulnerabilidad de BEAST se ha resuelto en el lado del cliente, por lo que ya no es un problema con los navegadores modernos.
RC4 es un código más débil que otros, ya que se ha demostrado que tiene un ligero sesgo, pero si se usa con cuidado y de manera apropiada, no hay ataques exitosos contra él.
No puedes estar más seguro que seguro; Si su cifrado no se puede romper, entonces no importa cuánto más no se pueda romper. Entonces, en ese sentido, no hay una razón convincente para evitar el cifrado.
Dicho esto, no tiene sentido utilizar un cifrado sesgado cuando hay otros disponibles. Así que en el futuro, es mejor que prefieras algo más. La razón principal por la que RC4 es tan persistente es que es el último cifrado de flujo verdadero en uso, lo que lo hace útil para las personas que desean evitar pensar en el encadenamiento de bloques. Los cifrados de bloques seguros son lo suficientemente difíciles de inventar; pero los cifrados de flujo están en un nivel completamente nuevo, por lo que no es probable que veamos otro.
Lo más probable es que RC4 continúe quedándose; No hay un reemplazo directo convincente. No lo preferiría, pero esperaría seguir viéndolo.
Muchas de las personas que recomiendan RC4 para evitar BEAST se han retractado debido a los ataques que se le han hecho; La solución correcta y con visión de futuro es actualizar su software a la especificación TLS 1.1.
Estratégicamente, tus opciones dependen de tus habilidades. Si se le permite dictar a los agentes de usuario que se conectan a su servicio, o está dispuesto a aceptar que su agente de usuario podría no poder conectarse a algunos servicios si eso lo hace más seguro, requiere soporte de TLS 1.2.
Es muy poco lo que se puede hacer de manera significativa para proteger a los usuarios que utilizan software obsoleto con vulnerabilidades conocidas. Esto incluye a personas que ejecutan agentes de usuario que aún no pueden ser mejores que SSLv3 y que no tienen soporte para los modos GCM.
Las suites de cifrado se negocian en un orden de prioridad. Como algunas personas podrían seguir el antiguo consejo de preferir RC4 para mitigar BEAST, es probable que sea una buena opción para desactivar RC4, especialmente si sus agentes de usuario (o los de sus usuarios) están actualizados.
Dado que los ataques prácticos se han demostrado con requisitos previos similares tanto para BEAST como para RC4, la elección es igual.