Sí, eres vulnerable a los ataques MITM debido al hecho de que estás comenzando con una aplicación web sin cifrar. Aquí es donde tiene lugar el ataque, ya que el atacante podría modificar cualquier referencia a https://secure.bank.com y reemplazarla con http://secure.bank.com . El atacante luego interceptará sus datos y transmitirá el contenido a la conexión segura real en https://secure.bank.com
Se recomienda encarecidamente forzar SSL desde el principio de la sesión, y debes asegurarte de anunciar solo la URL segura.
¿Esto es todavía vulnerable al ataque MIM?
Sí, lo es, porque probablemente iría con cookies de sesión que podrían ser rastreadas a través de un complemento del navegador como firesheep o man-in-the-middle'd fácilmente.
¿Cuáles son las precauciones?
La mejor práctica hoy en día es que toda su aplicación se ejecute sobre HTTPS porque:
Para garantizar HTTPS en todo el sitio:
http://site/resource a https://site/resource como el único patrón en esta configuración, por lo que si alguien escribe http://site/somepath , siempre será redirigido al sitio seguro Todo lo demás, como el inicio de sesión solo con cifrado está desactualizado; busca "cortafuego"
Después de visitar http://normal.bank.com , un atacante puede reemplazar todos los enlaces a https://secure.bank.com con enlaces a http://secure.bank.com . Cuando el usuario hace clic en http://secure.bank.com , el MITM se conectará felizmente al servidor a través de HTTPS y devolverá el contenido al cliente a través de HTTP. No importa qué precauciones de redirección se utilicen aquí, el MITM puede evitar toda la redirección.
En conclusión, sí, todavía eres vulnerable a los ataques MITM.
Voy a oponerme a la tendencia aquí y diré que es aceptable redireccionar así.
Es cierto que un usuario es vulnerable a MITM si va a enlace y continúa usando el sitio sin más controles de certificados , URLs, etc.
Sin embargo, este es un problema del comportamiento del usuario, y no es algo que pueda arreglarse en el servidor.
Solo pensemos por un minuto cómo podría intentar arreglar este lado del servidor. En lugar de emitir un redireccionamiento, puede mostrar una página informativa, tal vez con una advertencia fuertemente redactada "Para acceder a este sitio de forma segura, debe usar enlace " O puede hacer que el servidor web solo escuche en el puerto 443 y rechace el puerto 80.
Ahora, ¿qué sucede si un atacante tiene el control total de la red de un usuario? Cuando el usuario accede a enlace , el atacante los redirige a enlace y presenta una página de phishing. O tal vez insertan una página de phishing directamente en enlace De cualquier manera, un usuario experimentado y alerta podría detectar esto, pero muchos usuarios continuarán.
No importa el comportamiento real de enlace : el atacante puede hacer lo que quiera.
Así que, en última instancia, se trata de un problema de capacitación del usuario. Y el comportamiento del sitio puede influir en esto. La gran mayoría de las veces que un usuario visita el sitio, visitará el sitio real y no un ataque MITM. Si el sitio los redirige automáticamente, esto no hace nada para desalentarlos a usar la URL de http en el futuro. Si reciben un mensaje de advertencia, o el sitio simplemente no funciona, aprenderán rápidamente a usar los https de forma predeterminada.
¿Pero qué tan responsable eres como operador de sitio para capacitar a tus usuarios de esta manera? La realidad es que la gran mayoría de los sitios redireccionan de http a https de esta manera. Desde un punto de vista empresarial, ¿por qué hacer que su sitio sea más difícil de usar que los competidores? Si solo estás haciendo esto, ¿realmente vas a tener un efecto en el comportamiento general del usuario?
Por esas razones, en general, recomiendo que la mayoría de los sitios redirijan de http a https de esta manera.
Para bloquear esto tanto como sea posible, te recomiendo que configures la redirección para que enlace redirija a enlace - eliminando el resto de la URL.
No se mencionó explícitamente hasta ahora, por lo tanto esta respuesta tardía. Los sitios web que cambian entre HTTP y HTTPS son inevitablemente propensos a SSL-strip . Una buena explicación que puedes encontrar aquí:
presentación de la tira SSL de Moxie Marlinspike
Algunos puntos importantes:
Escribí una publicación en el blog al respecto hace unos meses. En la publicación de mi blog, mostré cómo redirigir el tráfico de http a https podría ser potencialmente peligroso dependiendo del mecanismo seleccionado. Propuse HSTS (HTTP Strict Transport Security).
Lea otras preguntas en las etiquetas web-application tls