¿Cuáles son las preocupaciones de privacidad sobre esto?
El análisis de contenido al interceptar SSL como un hombre activo en el medio solo se puede hacer si el cliente confía en la CA del hombre en el medio porque esta CA emite un nuevo certificado. Por lo tanto, por lo general, solo funcionará de manera transparente en las redes de la empresa, donde los sistemas se administran de manera centralizada y tales CA pueden instalarse. También funcionará si el usuario anula las advertencias o si el software no valida correctamente los certificados.
Si la intercepción es realizada por una parte confiable (es decir, un empleador o similar) que tiene el control del sistema de todos modos, las implicaciones de privacidad adicionales debidas a la intercepción SSL probablemente sean un problema menor porque esta parte confiable ya tiene acceso al sistema y por lo tanto, en teoría, también podría capturar los datos simples fuera de la conexión cifrada.
Las implicaciones de privacidad son más graves si el usuario no tiene conocimiento de la inspección y, por lo tanto, transfiere datos confidenciales en la creencia de que no pueden ser interceptados. Esto es especialmente problemático si estos son datos privados. Sin embargo, el uso de sistemas controlados por la empresa para el manejo de datos privados confidenciales es un problema de todos modos y no está restringido a la intercepción SSL.
Aparte de estas interceptaciones legales, existen formas ilegales al utilizar certificados de confianza conocidos por el atacante. Según entiendo la pregunta, esto no es sobre lo que pregunta, pero vea historia sobre el adware Superfish para un ejemplo.
¿Hay alguna forma para que los sitios web eviten que esto suceda a sus usuarios?
Es difícil para los sitios web detectar la intercepción SSL, pero sería posible en muchos casos. Dado que la intercepción SSL básicamente termina la conexión SSL del cliente en el proxy MITM y crea otra conexión SSL del proxy al servidor, el protocolo de enlace TLS que llegará al servidor será del proxy MITM y no del cliente original. Al tomar las huellas dactilares de los protocolos y compararlos con los navegadores típicos y las soluciones MITM, es posible determinar si es probable que se realice la intercepción SSL. Para obtener más información, consulte el capítulo Heurística de implementación TLS en El impacto en la seguridad de la intercepción de HTTPS .
Pero, en realidad, la información necesaria para tomar las huellas dactilares de la pila TLS no está expuesta a la aplicación, sino que se mantiene dentro del motor TLS del servidor web. Por lo tanto, una aplicación web en sí misma generalmente no puede determinar si la inspección TLS se realiza o no.
Otra forma de impedir la intercepción de SSL desde el servidor es exigir certificados de cliente. La mayoría de las soluciones de intercepción SSL no pueden lidiar con esto e incluso si pudieran necesitar volver a emitir el certificado del cliente de la misma manera que lo hacen con el certificado del servidor, que puede ser detectado por el servidor porque la CA del emisor no es confiable. Desafortunadamente, esto significaría que primero tendría que emitir certificados a todos los clientes que necesitan instalar. Si bien es útil si desea utilizar estos certificados para la autenticación del cliente de todos modos, en la mayoría de los casos sería una pesadilla logística y de usabilidad.
¿El HSTS lo previene?
HSTS simplemente dice que HTTPS solo debe acceder al sitio. Dado que HTTPS aún tiene acceso al sitio, aunque el tráfico sea interceptado, este encabezado no ayudará. Más útil en teoría podría ser la fijación de certificados, ya sea utilizando el encabezado HPKP o usando built-in pinsets . Pero mientras que la fijación de claves detectaría si el certificado se cambió debido a la intercepción de SSL, se deshabilita explícitamente si el nuevo certificado fue emitido por una CA que se agregó explícitamente como confiable. Esto se hace para admitir la intercepción SSL legal, como lo hacen las empresas, pero también en muchos productos antivirus.