¿Modelo de amenaza para grandes advertencias en certificados SSL no confiables y sin advertencias para conexiones HTTP simples? [duplicar]

No es un modelo de amenaza , es un modelo de negocio . Los navegadores web no pueden advertir sobre HTTP simple porque eso sería advertir sobre toda Internet (no es una mala advertencia, en realidad, sino una que los usuarios ignorarán rápidamente). Los navegadores web do advierten sobre problemas de certificados con SSL porque los intentos de phishing exitosos son una mala publicidad. El proveedor del navegador debe poder mostrar que "hacen algo al respecto", y esas son las advertencias de miedo.

La justificación teórica es que los usuarios están obviamente capacitados y saben que en ausencia del ("in)" icono de candado "famoso no hay seguridad. Así que no necesitan advertencias para HTTP simple; la falta de candado debería ser suficiente.

(Se necesita un poco de entrenamiento para poder decir eso sin burlarse).

Creo que tiene que ver con el comportamiento de las personas y cómo ha evolucionado Internet.

Recuerdo que había cajas de advertencia modales en IE y Netscape cada vez que se realizaba el primer envío de un formulario a través de una conexión HTTP simple, y había una casilla de verificación que decía 'No me avise otra vez'.

A medida que los usuarios de Internet se han acostumbrado a HTTPS, están más preocupados por la protección contra el phishing, lo que estas grandes advertencias de RED intentan lograr. Un vendedor minorista del Reino Unido fue víctima de una estafa de suplantación de identidad (phishing), y las primeras advertencias provinieron de clientes que vieron algo sospechoso en el SSL: el icono de "candado". Esto fue justo antes de las advertencias de la pantalla ROJA, hace aproximadamente 3 años.

Entonces, el modelo de amenaza es el mismo. La forma en que los usuarios de Internet (y los compradores) perciben y reaccionan a ellos está cambiando.

Aunque creo que las otras respuestas tienen un punto válido con respecto a los motivos financieros de los proveedores, aún creo que existen razones válidas para mostrar la "advertencia de gran miedo" en el caso de certificados SSL no confiables.

Tal vez lo más peligroso no es alguien que no espera seguridad (conexión http simple, aunque es discutible si el público en general lo sabe), sino la persona que espera seguridad, y no la recibe.

Sí, muchas veces los certificados vencidos pueden no ser súper peligrosos, pero estas advertencias pueden ser indicadores de un ataque MitM en curso, por lo que ciertamente quiero una advertencia fuerte cuando ocurra en un sitio web bancario donde tengo una expectativa de seguridad .

Resumen - Dadas las cosas se podrían dividir en conexiones inseguras (http) y conexiones seguras (https), creo que es razonable advertir a las personas en mayor grado cuando la seguridad que cree que funciona no funciona como se esperaba, ya que a diferencia de la (supuestamente) elección inteligente de utilizar una conexión insegura en primer lugar.

Me estoy haciendo la misma pregunta. Permítanme comenzar por resumir (y abordar) las razones que encontré aquí y en otros lugares, y luego explicar la única buena razón que encontré hasta ahora.

1. En primer lugar, los certificados autofirmados no protegen contra los ataques de intermediarios porque no prueban la identidad del sitio web al que te estás conectando. Es decir, son esencialmente inútiles / solo demuestran que estás hablando con el mismo sitio cada vez.

   Esto es cierto, pero en muchos escenarios, ese tipo de seguridad débil es lo suficientemente bueno . No todo el mundo está ejecutando un sitio de banca en línea. Ejecuto una pequeña comunidad de foros en un servidor virtual, y un certificado ssl sería un costo significativo en relación con mis otros gastos de hosting. Por consiguiente, ahora no uso ningún cifrado y, por ejemplo, en un WiFi público cualquiera puede leer las contraseñas o las cookies de sesión de mis usuarios cuando inician sesión.

   El uso de un certificado autofirmado aquí permitiría un aumento significativo de la seguridad, pero las advertencias del navegador asustarían a las personas.

   Los

   sitios donde la seguridad es esencial necesitan certificados de confianza. Sin embargo, la poca seguridad que ofrece el cifrado seguirá siendo una mejora para los sitios con pocas necesidades de seguridad que ahora no utilizan ningún cifrado.

2. Mostrar al usuario que una conexión está encriptada sin una advertencia creará una falsa sensación de seguridad. Los sitios de phishing podrían usar eso para falsificar una "página de inicio de sesión segura".

   Luego, no le muestra al usuario que la conexión está encriptada. No muestre ninguna diferencia aparente a una conexión no cifrada. Si el usuario consulta los detalles de la conexión de alguna manera (por ejemplo, al hacer clic en el favicon en Chrome), muéstrele que la conexión está encriptada, pero advierta que es insegura, con la información que se presenta actualmente en la pantalla de advertencia.

3. Pero el usuario aún puede esperar una conexión segura simplemente del prefijo de protocolo https:// .

   Este es el único argumento bueno que encontré hasta ahora, y en realidad es difícil de solucionar. Tal vez podríamos crear un nuevo prefijo de protocolo específicamente para las conexiones que están cifradas pero no seguras, como cttp (protocolo de transferencia de texto cifrado). Tal vez sea lo suficientemente bueno como para pasar por el https y mostrarle al usuario algún mensaje informativo con el mouse-over, como "Conexión insegura. No ingrese información confidencial". - Pero luego estamos de vuelta en tierra de advertencia.

Espero que esto sea lo suficientemente bueno para una respuesta, ya que describe por qué se necesitan las advertencias, a pesar de que la mayoría lo escribí para pensar las cosas por mí mismo. :)

Si no utiliza SSL, no está diseñado para ser seguro.

Las advertencias indican que la seguridad esperada está rota. La falta de seguridad no es seguridad rota.

Quizás la amenaza sería si pudiera detectar que existe la necesidad de seguridad TLS / SSL, pero el sitio no la ofrece. Por ejemplo, filtra el DOM y detecta un campo llamado "nombre de usuario" y uno llamado "contraseña", pero la página no se presenta en HTTPS. Luego, puede alertar al usuario "hey, es posible que no desee iniciar sesión en este sitio, van a transmitir su contraseña en texto sin formato". Probablemente podríamos pensar en algunos otros escenarios como un campo llamado "ssn" que requiere un número de 9 dígitos o un número de 16 dígitos que se ejecuta a través de una verificación local de dígitos de control.

Eso realmente suena como que podría ser un complemento útil, probablemente algunos falsos positivos aquí y allá, pero potencialmente podría ayudar a proteger a las personas.