¿Qué impide que alguien redirija una conexión HTTPS a una versión HTTP del sitio?

La decisión sobre si usar HTTP o HTTPS es del cliente.

Si el usuario va directamente a http://example.com , un atacante podría simplemente secuestrar esa conexión y realizar un ataque de hombre en el medio. Si el usuario va directamente a https://example.com , entonces el atacante debe falsificar la conexión SSL / TLS de alguna manera; hacerlo sin mostrar al usuario una advertencia de certificado no válido requiere que el atacante tenga acceso a la clave privada de una Autoridad de certificación. Esta situación nunca debería suceder. Sin esto, el navegador del usuario rechazaría la conexión y no permitiría que el atacante redirigiera.

En el caso de Google y varios otros sitios web, configuran el encabezado de Seguridad de transporte estricto de HTTP (HSTS), lo que hace que el navegador del usuario almacene en caché una regla que indique que nunca deben visitar el sitio a través de HTTP de texto sin formato, incluso si el usuario lo solicita o si Google lo redirige a una URL HTTP. El navegador volverá a escribir automáticamente la URL en HTTPS o bloqueará la solicitud por completo. Esto también evita que el usuario haga clic en una advertencia de certificado en la mayoría de los navegadores; la opción simplemente no está allí.

No, la búsqueda de DNS no le dice al cliente si debe conectarse a través de HTTP o HTTPS. El navegador decide que, si ingresa una URL HTTP, solicitará sin TLS en el puerto 80, y si ingresa una HTTPS, solicitará con TLS en el puerto 443. Así que es el cliente, y no el servidor, quien decide.

Si el servidor recibe una solicitud a través de un protocolo, no prefiere que pueda emitir una redirección respondiendo con un código de estado 300 y un encabezado de ubicación. Sin embargo, si la solicitud original es más de HTTPS, el intermediario necesitaría un certificado válido para poder enviar esa respuesta. Y si tuviera eso, no habría necesidad de redirigir a HTTP en primer lugar.

En primer lugar, creo que lo más importante que se perdió el OP es que la negociación SSL / TLS ocurre primero. Solo la conexión segura DESPUÉS se negocia y se valida, puede haber cualquier comunicación HTTP. HTTPS es un nombre incorrecto, es solo que su antiguo HTTP simple solo se envía a través de SSL / TLS completamente independiente.

  

Si el sitio real tiene un certificado SSL / TLS, eso detendría el   hacker de redireccionar digamos google.com a su propio servidor?

Los certificados se verifican y TLS se establece antes de que se realice cualquier HTTP. Con certificado incorrecto, la conexión nunca se establecerá en primer lugar. No hay espacio para redirecciones.

  

¿El servidor web no determina si se conecta a través de HTTP o HTTPS?

No, el cliente lo hace. Ya sea abriendo el socket y enviando la solicitud HTTP en texto sin formato, o abriendo el socket, realizando una negociación SSL / TLS completa y luego enviando la solicitud HTTP.

  

Y la búsqueda de DNS se realiza antes de que se conecten al servidor.

Sí, pero el cliente compara el certificado con el nombre DNS. Por lo tanto, puedo hacer que el DNS te engañe para que me acerques a mí en lugar de a Google, pero todavía necesitaré un certificado emitido para google.com

  

¿No podrían simplemente decirle al cliente que se conecte a través de HTTP en lugar de HTTPS?

No. Nunca tienen la oportunidad de hacer esto.

Si tiene una autoridad de certificación que validará cualquier certificado para cualquier dominio, entonces es cuando tiene un gran problema. Antes de que los navegadores identifiquen los certificados, esto se hace solo para los dominios en los que están interesados, todos los demás tienen que depender de que las CA no se comporten mal, por lo que hay un depósito de certificados SSL recopilados con los que puede verificar si cambia de spoofing. O más bien debería haber.