2010-06-20 10 views
5

En el modelo de seguridad HTTPS, la parte más débil es la lista de CA de confianza en el navegador. Hay muchas formas en que alguien puede inyectar CA adicional a la lista en la que los usuarios confían en el tipo equivocado.Cómo evitar el ataque hombre-en-medio HTTPS desde el servidor?

Por ejemplo, una computadora pública o una PC en su empresa. El administrador podría obligarlo a confiar en una CA emitida por él mismo, podría ser muy inseguro con un servidor proxy HTTPS con retransmisión HTTPS. Como resultado, podrán SPY su mensaje, inicio de sesión y contraseña, incluso el navegador le dirá que su conexión SSL es confiable.

En este caso, ¿qué puede hacer el desarrollador de aplicaciones web para proteger al usuario y también al sistema?

+1

Para instalar un certificado de CA raíz confiable, se requiere acceso al equipo de los usuarios. Una vez que tiene acceso a una máquina, hay maneras mucho más sencillas de robar datos que instalar un certificado, por lo que este escenario no es realmente válido en términos de la utilidad de la seguridad SSL. SSL es más para proteger de los ataques de hombre en el medio, donde un usuario simplemente está olfateando el tráfico enviado a través del cable sin acceso directo a la máquina de los usuarios. – TheCodeKing

Respuesta

4

Como desarrollador de aplicaciones web, hay muy poco que puede hacer al respecto.

Este problema debe abordarse más abajo en la pila.

Si alguien a mitad de camino en todo el mundo quiere:

a. Coloque una CA raíz falsa en la computadora de alguien

b. Emita un cert para su dominio bajo esa CA

c. Suplantar su sitio

d. Señale la entrada de DNS local de alguien para su dominio a una dirección IP diferente

En ninguno de los pasos anteriores es su aplicación involucrada o consultada, por lo que aquí es donde la buena administración de red y la seguridad son importantes.

Aparte de eso, tal vez haya una razón legítima para que alguien haga esto localmente en su red personal. ¿Quién soy yo para detenerlos?

Esto es esencialmente lo que hacen los filtros de proxy web corporativo y tienen el derecho de hacerlo.

En cuanto a detener a alguien malicioso de tomar los pasos anteriores, eso es algo que debe ponerse en los administradores de las máquinas de sus clientes.

+0

Alguna pregunta reciente http://stackoverflow.com/questions/19993696/is-there-any-way-to-access-ssl-certificate-details-using-javascript me indica una solución posible. Este proyecto https://github.com/digitalbazaar/forge puede ayudar a JavaScript a leer información SSL, podría ayudar a tener algún tipo de alerta si el nombre del emisor de CA no coincide. –

1

Teóricamente hablando, si el terminal del usuario es propiedad de un adversario, ya has perdido y no hay nada que pueda hacer al respecto - si el momento lo que puede filtrar sus contramedidas o incluso raspar y la parodia todo el sitio

En la práctica, puede hacer cosas para dificultar el trabajo del adversario, pero es una carrera de armamentos. Es probable que tenga que usar los mismos tipos de contramedidas que usa el software malicioso contra los escáneres, ¡porque desde el punto de vista del adversario su sitio se comporta con malicia al tratar de evitar que se anule! - y sepa que cualquier cosa que haga puede ser contrarrestada rápidamente si a su adversario le importa lo suficiente.

Podría, por ejemplo, abrir sockets o usar XmlHttpRequest desde JavaScript o applets, pero no puede evitar que su adversario actualice sus filtros para quitar todo lo que agregue.

Puede obtener más kilometraje emitiendo salida polimórfica o utilizando otras técnicas de ingeniería inversa, por lo que parece que no hay dos visitas al sitio que produzcan códigos/recursos similares enviados al navegador.Es una cantidad desmesurada de trabajo, pero le da a tu adversario un acertijo para morder si quiere jugar al hombre en el medio.

Cuestiones relacionadas