¿Debemos obligar a los usuarios a HTTPS en el sitio web?

Establezca una regla que redirija cualquier intento de acceso al sitio a través de HTTP, a la página principal a través de HTTPS (redirija cualquier intento de acceso a cualquier elemento que coincida con http://www.example.com/* a https:/www.example.com/ ).

Habilite HSTS . Esto le indica a los navegadores que se conecten a su sitio a través de HTTPS en el futuro.

Establezca el indicador secure en todas las cookies.

Asegúrese de que las páginas entregadas a través de HTTPS no carguen ningún contenido a través de HTTP.

Lea las siguientes preguntas en este sitio:

• ¿Es segura una reescritura forzada de http a https? ¿Qué agrega SSLRequireSSL?

• Seguridad adicional de HSTS sobre HTTPS

• Guía para implementadores de sitios que solo utilizan HTTPS (lado del servidor)

• ¿Opciones al defenderse contra SSLstrip?

• Seguridad de transporte estricta: valor de max_age

• ¿Cuáles son los pros y los contras de SSL (https) en todo el sitio?

Si su sitio utiliza autenticación, también debe usar HTTPS durante la vida de la sesión.

Esa condición de reescritura es insegura. Un atacante aún puede secuestrar la redirección con una herramienta como SSLStrip, y si el usuario está publicando información confidencial, se filtrará. Debería habilitar HSTS para aplicar HTTPS y leer Owasp A9 - Insufficient Transport Layer Security .

Esto depende completamente de sus objetivos de seguridad, que no haya declarado. Si usted es un sitio bancario, entonces sí, fuerce todos los accesos https. Si usted es un motor de búsqueda que tiene cuentas de usuario, entonces puede utilizar un modelo donde algunas páginas tienen https forzados. Si los beneficios de seguridad de forzar todos los https superan los inconvenientes de su modelo de negocio, entonces hágalo; de lo contrario, acepte los riesgos de seguridad.

Si deja alguna de sus páginas inseguras, todas sus páginas son inseguras, ya que cualquiera entre sus usuarios y usted (como otras personas en una cafetería) puede interceptar fácilmente todo el tráfico y reemplazar https:// links con http:// enlaces. Luego, pueden hacer lo que quieran con cualquier página de su sitio (como reemplazar la página de inicio de sesión con la suya, y luego obtener acceso a cualquier cosa que el usuario haya almacenado en su sitio).

Hay dos maneras de manejar esto (y van juntas):

• Use HTTPS en cada página. De esta manera, sin importar cómo llegue el usuario a su sitio (sin importar qué marcador use), siempre irán directamente a la versión segura.

• Utilice Seguridad de transporte estricta de HTTP . Esto lo hace así, una vez que el navegador de un usuario ha visitado su sitio una vez, se negará a conectarse a la versión insegura durante algún tiempo. Esto no es tan bueno como podría ser, pero es mucho mejor que nada.

Las únicas desventajas de esto son:

• Algunos servicios, como Google Translate, están dañados.
• HTTPS toma una cantidad de potencia de procesamiento completamente insignificante. Esta excusa casi tuvo sentido hace 10 años, pero nuestras computadoras son tan rápidas ahora, a menos que seas Google, ni siquiera lo notarás. Si eres Google, puedes permitírtelo para mantener felices a tus clientes.

Debería quedar claro a partir de las respuestas, no hay una respuesta correcta o incorrecta. Muchos factores deben tenerse en cuenta.

Es cierto que https puede agregar algo de sobrecarga. Sin embargo, con la tecnología actual del servidor, no estoy convencido de que este sea un problema tan grande como lo era antes.

SSL / TLS no es una solución mágica que automáticamente hará que su sitio sea seguro. Es solo una parte de una estrategia. Muchas violaciones de seguridad se deben a que los datos del servidor de back-end se ven comprometidos a través de otros canales y fallas en el almacenamiento / administración de datos de forma segura.

Si bien puede ser cierto que hay menos necesidad de usar SSL en las páginas que no tienen implicaciones de seguridad obvias, sería muy cuidadoso. El problema es que un sitio mixto agrega complejidad y mayor posibilidad de errores. Esto es particularmente relevante si su sitio es grande, complejo o tiene múltiples desarrolladores. Dado que los gastos generales asociados con el cifrado no son tan altos como solían ser, en general, si tiene una razón para usar https para algún contenido, preferiría usarlo para todo el contenido del sitio.

Voy a estar de acuerdo con Rook

Si su sitio web tiene partes públicas, déjelo como http normal, no hay razón para agregar carga adicional a sus servidores y usuarios. Ahora, si tiene usuarios que inician sesión y hacen algo, tienen un servicio para protegerlos. Desde el momento en que llegan a la página de inicio de sesión hasta el momento en que cierran la sesión, todo debe hacerse en https. Asegúrese de que cuando configura las cookies de los usuarios como solo para https, también querrá emplear algo en el lado de java-script para verificar si tienen cookies https y si lo hacen deberían forzar el redireccionamiento a https de esta manera, nunca lo hará. Transmitir las cookies de los usuarios a través de http.

La confianza es que no puede poner fin a su seguridad con solo asegurarse de forzar contraseñas seguras, tiene buenas políticas de hash y posibilidades de almacenamiento de datos en reposo. Depende de la aplicación que tenga, pero a menos que se cubra en todos los puntos, solo le pide a alguien que pruebe sus habilidades hasta que gane y publique la información de los usuarios de sus sitios en un torrente público.

De acuerdo con @Rook y @WojonsTech.

No es necesario https todo el sitio.

Por un lado, esto ralentizará su sitio web ...

Entonces perderá velocidad pero ganará muy poco (si es que algo) en términos de seguridad adicional.