¿Es posible forzar a un navegador a usar http en un sitio web con ssl habilitado (https)?

No se puede acceder a una página que está protegida con SSL (o TLS), a través de HTTP, ya que eso significaría que la página ya no está protegida.

Si reformulo la pregunta: ¿Es posible acceder a una página particular de un sitio web seguro de HTTPS a través de HTTP ? Entonces diría que es posible, pero muy INESeguro. Además, la cookie con el ID de sesión probablemente tendrá que enviarse junto con cada solicitud de página, ya que debe realizar un seguimiento de la sesión en varias páginas. Eso implicaría que necesita servir casi todas las páginas a través de HTTP, lo que hace que su sitio sea inseguro.

En caso de que necesite la cookie de sesión en una sola página, podría decirle al cliente que realice una solicitud HTTP a esa página, que luego enviará a lo largo de todas las cookies que no tengan el indicador de "seguro". Sin embargo, esto significa que todas estas cookies son vulnerables a un ataque MITM y pueden ser leídas por cualquiera que escuche su comunicación.

Mi consejo: nunca publiques conscientemente una página de un sitio HTTPS a través de HTTP.

Por lo tanto, la pregunta que debe hacerse es por qué mi ID de sesión no se puede etiquetar de forma segura solo . ¿Es la pereza o hay otra razón por la que no puede etiquetar esta cookie como segura?

Por cierto, para forzar a un navegador a usar siempre HTTPS para un sitio web (y no confiar en 302 redirecciones para visitar la versión de HTTPS), se puede usar HTTP Strict Transport Security. Consulte OWASP para obtener más información.

Sí, por supuesto.

• El ejemplo más simple es el usuario que acaba de enviar la solicitud como http: // ..., ya sea inconscientemente o por voluntad.
• El servidor web (potencialmente malicioso) también podría hacer eso, simplemente enviando una redirección 30x o una página con todos los hipervínculos adicionales apuntando a http: // en lugar de https: //

Ejemplo para el último: conéctese a enlace y llegará a una página sin ninguna protección SSL.

Creo que usted pregunta acerca de cifrar sus datos con ssl mientras accede a su servidor a través del protocolo http: //. Supongo que sería una buena solución para evitar todo tipo de advertencias de ssl y al mismo tiempo asegurar los datos importantes.

Me pareció muy interesante esa pregunta y seguiré intentándolo en mi propio servidor.

Pero, sobre la pregunta, el servidor no lo hará de manera predeterminada. Incluso si puede enviar la interfaz de escucha del servidor http a través de datos ssl, el navegador no manejará correctamente los datos solicitados. Piensa que el proceso de descifrado de los datos ssl es cuando alcanzas un contenido https: // url, por lo que seguramente se bloqueará de cualquier manera cuando se obtenga el cifrado porque no entenderemos las solicitudes, por diseño.

Si el objetivo es que las personas normales (con un navegador normal) estén casi al 100% seguras de que el navegador no funcionará con sus solicitudes.

Si el objetivo es enviar datos ssl mediante una conexión http procotol, debe hackear / modificar el servidor y el navegador bot, y, a través de un análisis de tráfico, se lo reconocerá como una conexión http con datos cifrados ssl "ilegibles" en él. .

Pregunta muy interesante. He comenzado una pequeña investigación sobre eso.

Sí, lo es

Si la negociación de TLS / SSL falla, entonces el navegador retrocede a HTTP (mientras permanece sobre el puerto HTTPS y la URL) , de la misma manera que puede retroceder a SSL3.
Tomé esta captura de pantalla mientras exploraba GitHub