¿Por qué los navegadores tienen como valor predeterminado http: y no https: para las URL escritas? [duplicar]

Bueno, puedo suponer que existen algunas razones:

1. La compatibilidad con HTTPS no se configura automáticamente en los sitios web. Por lo tanto, ¿por qué deberían los navegadores asumir que es?
2. Decir que no se puede acceder a un sitio web a menos que el uso de un esquema específico esté fuera del alcance de un número significativo de usuarios.
3. Cambiar a HTTPS no es tan simple como parece en algunos casos. Take Stack Exchange, por ejemplo.

En cuanto a mostrar sitios web inseguros en rojo, que ya está en progreso .

Google Chrome tiene la siguiente línea de tiempo para dar errores en sitios web inseguros:

1. Chrome 46

     

   Chrome marcará el estado "HTTPS con errores menores" utilizando el mismo icono de página neutral que las páginas HTTP.

2. Chrome 56

     

   marque las páginas HTTP que recopilan contraseñas o tarjetas de crédito como no seguras

3. Chrome 62

     

   Chrome mostrará la advertencia "No es seguro" en dos situaciones adicionales: cuando los usuarios ingresan datos en una página HTTP y en todas las páginas HTTP visitadas en modo Incógnito.

4. Chrome 68

     

   el omnibox mostrará "No seguro" para todas las páginas HTTP.

Los navegadores son aplicaciones para usuarios finales. Mientras que la mayoría de los sitios está disponible por http (incluso si solo redirigen a https) una parte importante no está disponible por https. Por lo tanto, su propuesta rompería la navegación web para una gran parte de los usuarios. Se rompería de una manera que ellos no entienden. La degradación automática a http si https falla no tendría sentido porque un atacante simplemente podría causar estragos en las conexiones al puerto 443 para imponer degradaciones.

Una vez que todos, excepto unos pocos sitios insignificantes, cambiaron a https, se podría cambiar a un valor predeterminado más seguro, pero aún no. Los usuarios finales no entenderían lo que sucedió y probablemente solo cambien a un navegador alternativo u obtengan algunos consejos de algún lugar de Internet para recuperar el comportamiento anterior.

Las decisiones de seguridad deben realizarse con los usuarios y no en contra de ellos.

Hay un problema mayor en juego aquí que evitaría tu sugerencia. La forma en que muchos servidores web están configurados actualmente, en realidad podría terminar en el sitio web incorrecto si se configura de forma predeterminada en https. Esto no es cierto si tu valor predeterminado es http.

Por ejemplo, suponga que tiene 3 sitios en la misma dirección IP:

http://site.a.com
http://site.b.com
https://site.c.com

En muchos servidores, si intentara ir a https://site.a.com , (en lugar de http), realmente estará mirando el sitio C, pero con un error de certificado.

Creo que existe un peligro real de confundir a muchos usuarios, lo que empeoraría la situación. Probar el HTTPS en todas partes no es necesariamente una mala idea, pero debe haber algún tipo de plan alternativo para el usuario cuando el HTTPS no esté disponible.

Muchos usuarios no están interesados en las señales de advertencia, solo quieren su contenido. En muchos casos, proteger el tráfico que recibe de las escuchas ilegales o los ataques MITM no es estrictamente necesario, o al menos el riesgo y las consecuencias son mucho más bajos que un certificado incorrecto en su banco.

Esencialmente, si los usuarios reciben una señal de advertencia cuando intentan acceder a su sitio favorito de HTTP (por ejemplo, un periódico o algún blog), tendría que enseñarles a ignorar la advertencia , porque todavía puede estar bien en este caso. Decirle a los usuarios que ignoren las advertencias es generalmente una idea terrible, a menos que realmente se asegure de que comprendan realmente ignorar que la advertencia está bien, pero que ignorar a los demás no lo es.

Las advertencias son buenas, pero numerosas advertencias para problemas de riesgo relativamente bajo son ineficaces, ya que es probable que los usuarios ignoren todas las advertencias (especialmente si no las comprenden completamente).

No muchos usuarios no tecnológicos intentan comprender las implicaciones de la advertencia de Firefox para un certificado incorrecto, por ejemplo:

  

Esta conexión no es de confianza

     

Le has pedido a Firefox que se conecte de forma segura a some.site.example, pero   No podemos confirmar que su conexión sea segura.

     

Normalmente, cuando intenta conectarse de forma segura, los sitios se mostrarán de confianza.   Identificación para demostrar que vas al lugar correcto.   Sin embargo, la identidad de este sitio no puede ser verificada. ¿Qué debo hacer?

     

Si normalmente se conecta a este sitio sin problemas, este error podría   significa que alguien está tratando de hacerse pasar por el sitio, y usted no debería   continuar.

Son tres párrafos que muchos usuarios no se molestarán en leer, al menos no cada vez que lo encuentren, si sucede con demasiada frecuencia.

La principal diferencia con un sitio HTTP simple es que el sitio HTTP simple no pretende ofrecer una conexión segura. Suponiendo que pueda explicarlo en otro mensaje de tres párrafos de manera similar. Sería bastante común, incluso para los usuarios expertos en tecnología que se distraigan y no lean esas explicaciones en su totalidad antes de continuar.

Muchos sitios utilizan redirecciones de http:// a https:// , a veces con el código de estado 301 (permanente) o con HSTS. El HSTS precargado es excelente pero raro, el HSTS en la primera conexión es un compromiso razonablemente bueno.

Al final del día, siempre dependerá del usuario esperar que la conexión sea segura cuando sea apropiado. El navegador solo puede hacer mucho, pero es responsabilidad del usuario verificar que HTTPS esté en uso cuando tenga sentido hacerlo, y con el sitio que esperan. No es particularmente diferente a la vida real: no es necesario verificar el pasaporte de todos con los que alguna vez hable, pero cuando las cosas importan, sí.

Hay un problema de arranque que no se puede transmitir dentro del ámbito de la tecnología. Si los usuarios van a http://www.gmail.com/ , deben redirigirse a https://www.gmail.com/ o tal vez a https://mail.google.com/ o https://accounts.google.com/ . Es un conocimiento fuera de banda que les dice que deben esperar HTTPS en Gmail, y que Gmail es administrado por Google. (El mismo conocimiento fuera de banda que les dice que incluso existe HTTPS ...)

Si no son redirigidos, a un sitio HTTPS ejecutado por Google (Gmail o inicio de sesión), esto es lo que debería sonar con ellos. Si bien un mecanismo automatizado podría funcionar para un número limitado de sitios conocidos, es difícil imaginar un sistema que funcione en general. Si falla, todavía necesita que el usuario tenga la responsabilidad de: (a) saber cuándo esperar HTTPS, (b) verificar que se usa HTTPS y (c) verificar que efectivamente están en el sitio que desean. (Desafortunadamente, algunos navegadores, especialmente en dispositivos móviles, hacen que la información sea un poco menos visible).

En mi opinión, es más fácil enseñarle a un usuario esos tres puntos que enseñarle a leer los detalles de las advertencias que pueden ignorar de todos modos.

Por supuesto, podría imaginar en el futuro un mundo donde todos los sitios utilicen HTTPS. Todavía no estoy completamente convencido de que esto sea necesario. Los sitios incorrectos también pueden obtener un certificado, por lo que los usuarios todavía tendrán que asumir la responsabilidad de verificar que estén en el sitio que pretendían visitar de todos modos.

Intentar enseñar que HTTP simple "no es normal" es simplemente llevar el problema al siguiente nivel. Una web totalmente HTTPS puede ser una carga para los proveedores de servicios, mientras que no necesariamente proporciona los beneficios que usted esperaría.

El EFF tiene un complemento para Firefox (incluido Android), Chrome y Opera. Se llama HTTPS Everywhere y usa reglas para asegurarse de que termine en el sitio correcto. Por ejemplo, reescribirá example.com en enlace si sabe que la versión https solo vive en secure.example.com. Incluso reemplaza urls dentro de enlaces etc.

enlace

En este momento, los navegadores utilizan HTTP de forma predeterminada porque es lo que se ha hecho durante décadas. No es responsabilidad del navegador garantizar que el sitio web sea seguro. Se basa en el sitio web para realizar la redirección y el soporte HTTPS adecuados. Escribir en google.com redirigirá a la versión HTTPS muy bien. Si un sitio web es compatible con HTTPS, debe colocar la redirección adecuada. El navegador tiene que ser robusto.

Si el sitio admite ambos, entonces es como decir que su puerta trasera se deja abierta, pero su puerta principal está bloqueada.

Debido a que las computadoras solían ser débiles y el cifrado tenía cpu y el ancho de banda de Internet estaba hambriento y se consideraba como no utilizado en la infancia de Internet ... Básicamente, empaqueta http en otra capa y lo empuja por la tubería. Esta capa adicional necesita hacer su propio tango ceremonial para poder trabajar, lo que significa cpu extra, viajes de ida y vuelta extra, ancho de banda adicional ... Pero las cosas están cambiando, por ejemplo, las versiones recientes de Chrome por defecto intentarán https hoy en día. Sin embargo, en el lado del servidor, debe configurar un redireccionamiento como el único contenido web que se sirve en dicho dominio y que apunta al navegador al aspecto https del sitio.

Cualquier sitio web que requiera seguridad debe redirigir de http: // a https: // automáticamente. Esto haría que el navegador viera automáticamente https: // redundante, y es una solución más sencilla que tener que redirigir de https a http para sitios sin certificados.

Esto es algo que realmente no debería hacerse de todos modos, lo que significa que el navegador tendría que poner advertencias de seguridad, molestando innecesariamente al usuario como esas molestas advertencias de cookies, etc.