Forzar todo el sitio https sin redirigir http a https

14

Hubo muchas discusiones mientras investigaba cómo hacer que todo mi sitio https. La mayoría de las respuestas fueron redirigir http a https (archivo .htaccess), lo que no es bueno, porque no es bueno hacer el mismo trabajo dos veces (dos solicitudes). Además, el "hombre en el medio" primero toma http, y quiero que mi sitio vaya directamente a https. ¿Hay otra forma de hacer que todo su sitio sea https y cómo hacerlo? Por ejemplo, cuando el usuario escribe en example.com, ¿ese example.com va automáticamente a https, sin redirigir desde http o cualquier otra cosa primero?

http  https 
— Marko Tamburic
fuente
si no desea que las personas sean redirigidas a https, ¿qué quiere que suceda?
— Michael Hampton
@MichaelHampton Tal vez estoy haciendo una pregunta para los novatos, pero quiero prácticamente "eliminar" http, y lo único que existe es https. O si esto no es posible, podría usar la redirección si es lo suficientemente bueno para la seguridad. Escuché que la redirección http-> https no es tan buena porque todavía es http y el tráfico puede ser interceptado durante la redirección.
— Marko Tamburic
El redireccionamiento permanente HTTP 301 es tu amigo, solo no olvides establecer caduca.
— Marcel
Simplemente puede eliminar http. Pero luego, el usuario recibe solo un mensaje de conexión rechazada, si no está ingresando https: // Para algunos sitios, esto es mejor, porque la seguridad es mayor. Si hay una versión http disponible, puede suceder que las cookies se envíen con la primera solicitud sin cifrar. Para cosas como el sistema de correo de una empresa, solo https + capacitación de usuarios está bien, para un sitio general probablemente perderá muchos visitantes.
— Josef dice Reinstate Monica
Afaik se hizo posible con HTTP2, sin embargo, aún no evitará el ataque de ssl striping (descrito en las respuestas a continuación).
— peterh - Restablecer Monica

Respuestas:

22

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security le permite a su servidor indicar que solo se debe acceder al dominio a través de HTTPS. Esto solo se aplica a solicitudes posteriores, por lo que habría una carga HTTP inicial, pero las solicitudes futuras cargarían HTTPS incluso si alguien escribiera HTTP explícitamente.

IE aún no lo admite, pero todas las otras especialidades sí lo hacen.

— ceejayoz
fuente
Todavía no protege contra la primera solicitud.
— Jenny D
3
@ JennyD Ya dije exactamente eso en mi respuesta.
— ceejayoz
@JennyD ¿Qué quieres decir con "proteger"? Un MiM no puede hacer nada en contra de una redirección http -> https, a menos que esté jugando con el dns / enrutamiento local y falsificando todo su dominio. En ese caso, realmente no importa lo que haga, ya que nunca se accede a sus servidores.
— Alerta roja
2
@JennyD Bueno, HSTS es realmente una mejor solución que su publicación, que dice "una redirección es la forma de hacerlo". Una redirección puede ser MITMed en cualquier momento. Una redirección con HSTS solo puede ser MITMed una vez al año por usuario + navegador (o cualquiera que sea el tiempo de vencimiento en el encabezado); en cualquier otro momento no se solicita.
— ceejayoz
1
@MarkoTamburic No hay razón para que no puedas combinar los dos.
— ceejayoz
7

Como han dicho otros, no puede obligar a los usuarios a elegir el protocolo correcto. Pero cuando el usuario intenta usar HTTP, ¿qué debe hacer? Una redirección también es insuficiente, porque un atacante que se sienta entre usted y el cliente puede interceptar la redirección, por lo que el cliente nunca la ve. El cliente continuará enviando HTTP simple, y el atacante eliminará la capa SSL del servidor ( ataque de eliminación de SSL ).

La única forma segura de evitar eso es no servir HTTP en absoluto . No responda en el puerto 80, excepto tal vez para servir una página de texto sin formato que indique al usuario que intente nuevamente con HTTPS (pero no proporcione un enlace, que el atacante podría manipular). Esto obligará al usuario a escribir https://en su navegador, por lo que iniciará la conexión con SSL y evitará el ataque MITM.

— Andrew Schulman
fuente
3
Sin embargo, es una compensación, ya que la mayoría de los usuarios no van a escribir https://. En cambio, van a decir "eh, el sitio está roto" y se irán. El mejor de los casos podría ser www.example.comresponder tanto a HTTP como a HTTPS, pero tener la aplicación ejecutándose en algo como admin.example.comsolo HTTPS.
— ceejayoz
Convenido. En la práctica, casi nadie hace esto.
— Andrew Schulman
Realmente no veo cómo eso sería más a prueba de MiM. Si el hombre en el medio puede modificar su hipervínculo para apuntar a otro lugar, significa que tiene el control de los paquetes entrantes del usuario. Puede redirigir fácilmente a su sitio o agregar cualquier hipervínculo que desee, independientemente de cómo se suponga que se vea el sitio.
— Alerta roja
Pero no, en teoría, si el cliente inicia la conexión con SSL.
— Andrew Schulman
3
eso es cierto, pero si el cliente inicia con SSL, OP no tiene ningún problema. Su problema es cuando inician sin SSL, y no hay forma de llevarlos a SSL de manera confiable si hay un MiM que sabotea activamente eso.
— Alerta roja
1

ceejayoz tiene la mejor respuesta para evitar el ataque específicamente mencionado aquí, pero también quiero señalar lo que falta a mucha gente aquí, que básicamente es que HTTP ya ha resuelto la otra parte. Desea hacer una redirección 301 permanente. Esto le dice al cliente que haga más solicitudes a la nueva dirección. Entonces, sí, si alguien escribe la URL incorrecta, realizará 2 solicitudes PERO, en el futuro, se supone que un buen cliente detectará las solicitudes a esa URL y realizará la solicitud correcta para evitar más solicitudes desperdiciadas. El problema es que esto es solo para esa URL exacta. HSTS mejora este esquema al decir también: "durante los próximos n segundos tampoco se permiten conexiones no seguras desde este dominio".

Los usuarios no deben visitar sitios sensibles en ubicaciones inseguras. Especialmente no deberían registrarse para ellos en lugares inseguros. Estos son principios básicos de seguridad del usuario que deberían enseñarse como, 'no abra archivos adjuntos de fuentes no confiables'. Cuáles son realmente la mejor respuesta para prevenir ataques MiM para sitios que nunca han sido visitados.

Como nota al margen, algunos navegadores mejoran esto al decir que ciertos sitios conocidos siempre usan HSTS. Desafortunadamente, no puede simplemente agregarse a esta lista fácilmente.

Lectura adicional: http://coderrr.wordpress.com/2010/12/27/canonical-redirect-pitfalls-with-http-strict-transport-security-and-some-solutions/

http://dev.chromium.org/sts

— krowe
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.