Pregunta Deshabilitando HSTS para los navegadores administrados


¿Cuáles son mis opciones para desactivar HSTS tanto para sitios nuevos como para aquellos sitios integrados en el navegador?

El uso de la inspección de HTTPS cambia de manera inherente la huella digital de un sitio al actuar como un hombre en el medio; Visitar un sitio visitado previamente sin la inspección HTTPS o uno de los sitios precargados resultará en un sitio inaccesible. ¿Qué opciones, si las hay, tengo otras que desactiven la inspección?

Aquí hay un ejemplo, Gmail en Chrome con inspección HTTPS:

Main Details

Fondo

Estoy configurando un nuevo firewall y estoy tratando de limpiar mis reglas de inspección de HTTPS. yo De Verdad desee evitar agregar sitios a la lista que puedan tener contenido contribuido por el usuario, como mail.google.com / gmail.com.

Desde la última vez que hice esto. Seguridad estricta de transporte HSTS / HTTP Se ha vuelto mucho más frecuente.

Nota: traté de mantener este genérico ya que podría ser un problema para muchas configuraciones diferentes. Espero un sistema de navegador cruzado / sistema operativo que sea aplicable a cualquier producto de firewall, pero eso es un poco complicado. Un enfoque en (IE, Chrome, Firefox) con Windows (7+) sería un gran comienzo. Los métodos centrados en la Política de Grupo también serían muy útiles.


7
2017-08-12 15:30


origen


Me está costando mucho entender esto. ¿Esto realmente está destinado a resolver algún problema? ¿Entonces qué? - Michael Hampton♦
@MichaelHampton bastante justo. Creo que lo hice un poco demasiado genérico. Necesito hacer que los sitios estén disponibles sin desactivar la inspección HTTPS. - Tim Brigham
@MichaelHampton, para probar cosas SSL básicamente. security.stackexchange.com/q/102279/2379 . O para permitir que un proxy realice la grabación (por ejemplo, JMeter). No importa si la configuración es increíblemente oscura (por ejemplo, que el usuario promedio nunca podrá hacer clic a ciegas), pero sí necesariamente para ser una manera de hacer esto. - Pacerier


Respuestas:


Estás confundiendo algunas cosas diferentes aquí, y sospecho que te está llevando a algunas conclusiones falsas.

  • HSTS ("Seguridad de transporte estricta de HTTP") trata (solo!) De exigir que HTTPS se use para conexiones a sitios específicos. No impone nada sobre qué claves, certificados, etc. se utilizan para autenticar la conexión.
  • La fijación de claves públicas especifica que, si se establece una conexión HTTPS con un nombre dado, la cadena de certificados debe incluir una lista blanca de claves públicas, de lo contrario, la conexión se considerará inválida.

Como la inspección de HTTPS es (desafortunadamente) una práctica ampliamente implementada, la práctica general entre los navegadores es que las cadenas de certificados que terminan en un certificado de CA raíz instalado localmente están exentas de las comprobaciones de fijación de claves públicas. He encontrado un declaración de Adam Langley de Chrome sobre el comportamiento de Chrome (la sección "¿Qué pasa con los proxies MITM, Fiddler, etc.?"), pero mi experiencia es similar para otros navegadores.

Estoy bastante seguro de que el problema indicado en su captura de pantalla no es que el navegador se esté quedando bloqueado en un pin, sino que no reconoce el certificado como encadenado a un certificado de CA de confianza. Eso provocará una falla de HSTS, porque "el uso de HTTPS" se especifica más correctamente como "el uso de HTTPS debidamente asegurado, incluidos los cifrados de seguridad y un certificado de confianza para la autenticación". Sugeriría una doble verificación de que el certificado de la CA raíz del proxy de MitM esté instalado correctamente y que sea reconocido como válido por los navegadores en uso.


5
2017-08-12 23:15