El reciente artículo publicado en slashdot enlace dice que las conexiones aseguradas con TLS 1.0 son susceptibles al descifrado del hombre en el medio (la explotación BESTIA). Tengo una aplicación alojada en Google Appengine, que parece usar TLS 1.0. Se basa en gran medida en javascript, por lo que no puedo recomendar a mis usuarios que lo desactiven. ¿Qué puedo hacer?
Teoría del BEAST Attack
SSL utiliza varias combinaciones de algoritmos de clave pública y simétrica. ( lista de OpenSSL ) Cuando el algoritmo simétrico es un algoritmo de bloque (a diferencia del flujo), el encadenamiento del bloque de cifrado se utiliza - el bloque anterior es parte de la entrada al nuevo bloque.
Los problemas que estamos viendo en este momento están basados en la implementación y se han hablado al menos desde 2002. Esto discusión de CBC señala que, en general, es realmente difícil construir el texto sin formato elegido en la mayoría de los protocolos. HTTP con Javascript permite que esto suceda.
¿Por qué seguimos sufriendo esto?
Deberíamos alejarnos de TLS 1.0 y pasar a la versión 1.2. Pero, por supuesto, aún vivimos en un mundo con SSL 2. Más al punto, incluso donde puede cambiar a las nuevas versiones de TLS en su servidor, el omnipresente NSS la biblioteca no lo admite. Eso significa que no obtendrás visitantes de Firefox o Chrome.
Puedes usar cifrados de flujo (RC4), y eso evitará el ataque. No sé si el mensaje de apertura vacío de mi primer enlace se usa en absoluto, o cómo afectaría esto a varias implementaciones de clientes.
Tu reacción personal
Ayuda a escribir TLS 1.2 en la biblioteca NSS. Haz que otros sepan que consideras la seguridad como una prioridad. Si tiene tiempo, investigue y pruebe qué configuraciones SSL no estándar funcionarán y qué plataformas afectan negativamente. Si descubre que RC4 funciona con todo, publíquelo para que sepamos que se ha probado.
Si no tienes el tiempo o la capacidad para eso ... espera. Eso sucede con demasiada frecuencia, pero al menos algunas personas son siendo chirriante al respecto.
Lo mejor que puedes hacer es esperar. No hay suficientes detalles conocidos sobre el ataque para evaluar si se trata de algo realmente real o no, o de cómo podría solucionarse. Algunos detalles sugieren un defecto en implementations y posiblemente se solucionen en los navegadores relevantes.
Mueve los conjuntos de cifrado basados en rc4 a la parte superior de la lista; el ataque parece estar relacionado con CBC, y rc4-sha no es vulnerable si ese es el caso.
Actualización: aquí hemos publicado un informe técnico que detalla cómo realizar los cambios. Disponible aquí . Para aclarar, la versión del protocolo no lo ayudará aquí debido a consideraciones prácticas: los servidores no pueden deshabilitar TLS1.0 / SSL3 en este momento debido a un mal soporte del cliente, y simplemente habilitar 1.1 aún lo deja abierto a un ataque de baja calificación, incluso si el cliente soporte 1.1. Ir a un cifrado que no sea CBC es la única mitigación efectiva del lado del servidor que conozco.
Además, mail.google.com ha cambiado a RC4, que no es susceptible al ataque, bien podría ser que el motor de aplicaciones de Google también haya cambiado. Si visita el sitio con SSL, puede hacer clic en el indicador de SSL en la barra de URL, hacer clic en "más información" y ver qué cifrado se está utilizando.
Puede obtener una mejor perspectiva en SANS Diary Entry en enlace la única manera posible (comentada en la entrada anterior) para contrarrestarlo en el Servidor se menciona como deshabilitar los cifrados utilizando CBC
Para una mejor comprensión de BEAST , podría tener acceso al Papel SSL para él y al Código Java en enlace
Lea otras preguntas en las etiquetas tls javascript beast