Me gustaría probar un servidor específicamente para detectar vulnerabilidades relacionadas con BEAST. ¿Qué modificadores de línea de comando debo usar?
¿Qué debo ver (o no ver) en la salida?
Update
La intención es escanear un servidor web no conectado a Internet o escanear un servidor que se ejecuta en un puerto no predeterminado. En todos los demás casos, podría utilizar Escaneo SSL para esta tarea
He escrito una herramienta de línea de comandos llamada TestSSLServer que se puede usar para ese trabajo.
La herramienta hace muchos apretones de manos abortados con el servidor (envía ClientHello y recibe ServerHello; luego cierra la conexión). Primero, establece la lista de suites de cifrado admitidas por el servidor, enviando una lista completa de muchas , y luego eliminando una por una la suite que el servidor selecciona cada vez.
Luego, la herramienta envía primero ClientHello, con el máximo de TLS versión 1.0, y los conjuntos de cifrado basados en CBC primero, seguidos de los no basados en CBC (conjuntos tomados entre los conjuntos "fuertes" que admite el servidor). Si el servidor selecciona un conjunto de cifrado no basado en CBC, entonces se considera "protegido" (el servidor aplica una opción que protege al cliente); si selecciona un conjunto de cifrado CBC, la herramienta informa "vulnerable" (nuevamente, la vulnerabilidad está en el lado del cliente, pero el servidor no puede aplicar la protección al cliente).
Antecedentes. Para obtener más información sobre cómo mitigar el ataque BEAST, recomiendo leer las siguientes dos publicaciones de blog: Rizzo/Duong BEAST Countermeasures y Mitigar el ataque de BESTIA en TLS . Aprenderás rápidamente que no hay realmente buenas soluciones.
En qué se debe buscar. En este momento, la única mitigación del lado del servidor conocida es que el servidor obligue al uso de RC4 al negarse a aceptar cualquier otro conjunto de cifrado. Una variación similar es colocar el conjunto de cifrado RC4 como la preferencia más alta; Esto es casi tan seguro, ya que garantiza que cualquier cliente que admita RC4 usará RC4.
Por lo tanto, cuando escanea un servidor SSL, si el servidor prioriza cualquier conjunto de cifrado basado en cifrado en bloque más alto que los conjuntos de cifrado RC4, entonces puede considerarse vulnerable al ataque BEAST. Si todos los conjuntos de cifrado que acepta utilizan RC4 (o si los conjuntos de cifrado RC4 tienen prioridad antes de cualquier bloque de cifrado, excepto los conjuntos de cifrado de solo TLS 1.2), es probable que esté a salvo del ataque BEAST.
La determinación de las prioridades del servidor en los conjuntos de claves puede ser complicada y puede requerir múltiples conexiones al servidor con un conjunto diferente de conjuntos de cifrado cada vez. Sin embargo, en este caso, un método simple puede ser que su cliente se conecte con una lista de conjuntos de cifrado que comience con todos los conjuntos de cifrado de bloques (no solo TLS-1.2), y luego finalice con algunos conjuntos de cifrado RC4. Si el servidor elige algún conjunto de cifrado de cifrado de bloque, entonces el servidor probablemente sea vulnerable al ataque de BEAST.
Idealmente, el servidor admitiría TLS 1.1 o superior. Si tanto el cliente como el servidor soportan TLS 1.1, entonces el ataque BEAST se vuelve mucho más difícil (requiere un ataque de intermediario). Por lo tanto, si el servidor no es compatible con TLS 1.1, es posible que desee emitir una advertencia / advertencia que sugiera que la actualización del administrador del servidor proporcione compatibilidad con TLS 1.1. Sin embargo, aparentemente el soporte de TLS 1.1 en ambos puntos finales no es una garantía absoluta de seguridad, debido a la posibilidad de ataques de baja calificación si hay un hombre en el medio presente, por lo que sugeriría que se enumere simplemente como una advertencia / aviso, más bien que un fallo crítico.
Más información sobre la exploración del servidor SSL. Es posible que desee considerar el uso del servicio SSL Labs para explorar una Servidor SSL Es una excelente manera de probar muchas posibles vulnerabilidades de configuración. También probará si el servidor es vulnerable al ataque BEAST, pero también buscará muchos otros problemas comunes y graves, lo que probablemente sea más útil que solo buscar el problema BEAST.
esto se basa solo en algunas búsquedas en línea, sin análisis detallados, pero de lo que recojo, es más una vulnerabilidad del lado del cliente que una de servidor. Por supuesto, la vulnerabilidad es cuando se ataca la comunicación entre el cliente y el servidor, pero la solución debe ser principalmente en el cliente . La razón principal, como lo entiendo, es porque el cliente selecciona sus cifrados preferidos y envía una lista ordenada al servidor para que 'elija'. El servidor generalmente debe aceptar la solicitud del cliente (pero no tiene que hacerlo). Ese es mi entendimiento limitado del saludo de manos de esta respuesta SO
Teniendo esto en cuenta, hay algunas soluciones de servidor que parecen ser efectivas. Una de ellas es evitar los cifrados en bloque que usan CBC, y por ejemplo, Utilice RC4 como alternativa. Esto puede ser aplicado por el servidor. Por supuesto, el uso de TLS 1.1+ también solucionaría el problema, pero, según tengo entendido, no está ampliamente soportado. Según el artículo de wikipedia en RC4
RC4, al ser un cifrado de flujo, es el único cifrado común que es inmune [6] al ataque BEAST de 2011
( [6] enlazando a serverfault :)
Para volver a los detalles de su pregunta. Supongo que lo lógico es verificar qué cifrados admite el servidor, y si es compatible con TLS 1.0 + uno de los cifrados de bloque con CBC que son vulnerables a BESTIA, se podría decir que el servidor es vulnerable a BESTIA. Parece que podría ser más fácil usar sslscan en lugar de openssl para enumerar todos los sistemas de cifrado admitidos por el servidor y de los servidores vulnerables descubiertos. / p>