¿Cómo se justifica el peligro / badidea / thisisunsafe?

1

El estándar HSTS establece lo siguiente:

  

12.1. Sin recurso del usuario

     

Fallo en el establecimiento de la conexión segura en cualquier advertencia o error   (según la Sección 8.4 ("Errores en un establecimiento de transporte seguro")) debe   hacerse con "ningún recurso del usuario". Esto significa que el usuario no debe   Se le presentará un diálogo dándole la opción de proceder. Más bien,   debe tratarse de manera similar a un error del servidor donde hay   nada más que el usuario pueda hacer con respecto a la interacción con el   aplicación web de destino, que no sea esperar y reintentar.

enlace

Puedo ver por qué para los hosts que no son HSTS (como los dispositivos de red) sería beneficioso tener una manera de evitar la advertencia rápidamente, para configurar e implementar un certificado válido, ya que estos dispositivos pueden salir de la caja. con un certificado inválido.

Dado que el estándar HSTS dice que no debería haber ningún recurso para el usuario, y que ya existe un indicador --ignore-certificate-errors que logra el mismo objetivo, ¿cuál es la justificación para brindar a los usuarios una forma más fácil de solucionar los problemas del HSTS? que limitar el bypass a hosts no HSTS?

    
pregunta jrtapsell 14.10.2018 - 14:11
fuente

2 respuestas

0

Probablemente está dentro de la especificación. La frase es cambiado regularmente , y no es algo por lo que te encuentres por casualidad. Tienes que saber lo que estás buscando (por ejemplo, google 'chrome hsts bypass'), lo que indica que eres consciente del riesgo.

La barra para usar esto es un lote más alto que hacer clic en "Continuar", ya que no está documentado en el mensaje de error que se muestra al usuario.

Además, realmente no hay autoridad certificadora cuando se trata de RFC. Algunas de ellas están abiertas a interpretación, y no hay un organismo oficial que le dirá si cumple con un RFC o no.

En mi opinión, tener una manera de evitarlo para los usuarios que sí entiende que las implicaciones son, ya que hace que sea más fácil de diseccionar si su propio sitio está bajo ataque, o si simplemente está investigando por ejemplo, un ataque de phishing contra su organización.

En resumen, es un acto de equilibrio entre ser imposible y realmente oscuro . Creo que el thisisunsafe es un saldo razonable. Es poco probable que sea utilizado por usuarios desconocidos, pero disponible cuando sea necesario.

    
respondido por el vidarlo 08.12.2018 - 21:11
fuente
1

Absolutamente, está justificado. El estándar HSTS es estrictamente incorrecto, aunque su redacción exacta agrega al menos dos advertencias que claramente permiten varias opciones, incluidas características "ocultas" como una frase secreta, una bandera de línea de comandos o incluso la capacidad de registrar un sitio. / dirección / certificado / etc. como de confianza. Todo lo que realmente no está permitido es el botón directo "proceder".

Por supuesto, uno solo debe usar cualquier solución alternativa de omisión de seguridad si sabe exactamente lo que está haciendo.

No estoy de acuerdo con que la frase secreta utilizada actualmente por Chrome sea ideal; y creo que la manta --ignore-certificate-errors es un martillo muy grande e inutilizable. Creo que el mecanismo empleado originalmente (al menos en macOS y creo que Windows) mediante el cual un certificado podría registrarse como confiable (quizás solo para sitios y / o usuarios específicos) fue infinitamente mejor, y el hecho de que Chrome ignora silenciosamente tales configuraciones ahora es Comportamiento abominable y un enorme paso en falso de UX.

De hecho, creo que el botón de "proceder de todos modos" solo un poco oculto debería haber permanecido en todas las páginas de advertencia, aunque quizás debería haber pedido su contraseña o alguna otra molestia.

La parte más molesta de la UX actual en Chrome es la estúpida sugerencia inútil de que el usuario pueda "esperar e intentarlo de nuevo".

    
respondido por el Greg A. Woods 15.11.2018 - 22:55
fuente

Lea otras preguntas en las etiquetas