Apache: ¿Validar la cadena de confianza SSL para evitar ataques MITM?

11

Me acabo de dar cuenta de que los ataques SSL de hombre en el medio son mucho más comunes de lo que pensaba, especialmente en entornos corporativos. Me he enterado y he visto varias empresas que tienen un servidor proxy SSL transparente. Todos los clientes están configurados para confiar en el certificado de este proxy. Básicamente, esto significa que, en teoría, el empleador puede interceptar incluso el tráfico cifrado SSL sin que surja ninguna advertencia en el navegador. Como se mencionó anteriormente, los clientes vienen con el certificado de confianza. Esto solo se puede revelar validando manualmente el certificado que se está utilizando.

Para mí, parece que el empleador utiliza su posición superior para espiar el tráfico SSL del empleado. Para mí, esto hace que todo el concepto de SSL no sea confiable. Yo mismo probé con éxito una configuración similar usando mitmproxy y pude leer la comunicación entre el cliente y mi servidor de banca electrónica. Esta es información que no debe ser revelada a nadie.

Por lo tanto, mi pregunta es bastante simple: ¿cómo puedo validar la cadena de confianza en el lado del servidor? Quiero asegurarme de que el cliente use el certificado de mi servidor y solo una cadena de confianza. Me pregunto si esto se puede lograr con la configuración SSL de Apache. Esto sería conveniente ya que podría aplicarse fácilmente a muchas aplicaciones. Si esto no es posible, ¿alguien sabe de alguna manera de hacer esto en PHP? ¿O tienes alguna otra sugerencia?

— Aileron79
fuente

1

Está bien si el empleador ve tráfico de empleados. Está utilizando los recursos del empleador (PC, conexiones de red, etc.), estos no son suyos. Y si le preocupa que el empleado pueda ver los datos que transmite a su cuenta bancaria, hágalo en casa, no en el trabajo. Y los intentos de violar la política de seguridad corporativa pueden ser objeto de un tribunal en su contra.

— Crypt32

2

En muchas empresas europeas, el uso privado de equipos de oficina está regulado en el contrato de trabajo. En la empresa donde trabajo puedo navegar en privado, eso no es un problema. Hay excepciones como pornografía, intercambio de archivos, etc. Al mismo tiempo, hay leyes que no permiten que las empresas espíen a sus empleados. Por lo tanto, para mí, y para muchos otros, NO está bien cuando los empleadores interceptan el tráfico de empleados, ya que esto está claramente prohibido, mientras que en muchas empresas se tolera la navegación privada.

— Aileron79

2

La mayoría (en mi experiencia) de las estaciones de trabajo propiedad del gobierno de los EE. UU. Incluyen estos dos avisos en cada inicio de sesión: "Las comunicaciones que usan o los datos almacenados en este IS no son privados, están sujetos a monitoreo, intercepción y búsqueda de rutina, y pueden divulgarse o usarse para cualquier propósito autorizado por el USG. Este IS incluye medidas de seguridad (por ejemplo, controles de autenticación y acceso) para proteger los intereses del USG, no para su beneficio personal o privacidad ". El uso de estos sistemas a menudo está cubierto por un acuerdo firmado que estipula lo mismo. El detalle clave es que el propietario del sistema se protege contra usted.

— Randall

Esa es una de las muchas diferencias entre Estados Unidos y Europa. Los términos @Randall citados anteriormente son ilegales en la mayoría de los países europeos.

— Aileron79

Los términos que cité están incompletos, otros términos enumeran actividades que no se deben monitorear explícitamente. No puedo encontrar ninguna referencia que indique que los empleadores europeos no pueden hacer que tales condiciones previas sean una condición para usar sus computadoras (trabajo para una compañía que opera en Europa, estableciendo dichos procesos de monitoreo, aunque trabajo para una división que no está haciendo negocios en Europa), pero puede encontrar referencias que sugieran que dichos términos no son ilegales siempre que sean explícitos y transparentes.

— Randall

9

Creo que esta pregunta sería más apropiada para security.stackexchange.com donde el tema de MITM se discute en muchas preguntas. Pero de todos modos:

La validación del certificado del servidor solo se realiza en el cliente y no se puede mover de alguna manera al servidor, ya que el punto de validación del certificado en el cliente es que los clientes deben asegurarse de que está hablando con el servidor correcto y no pueden confiar en el servidor (no confiable) para tomar esta decisión por el cliente.

En caso de intercepción SSL, el cliente TLS desde la perspectiva del servidor es el cortafuegos / AV interceptor SSL. Por lo tanto, el problema en el lado del servidor es detectar si está hablando con el cliente esperado (el navegador) o no (el firewall / AV). La forma más segura de hacerlo es usar certificados de cliente para autenticar al cliente; de hecho, la intercepción SSL no funcionará si se usa la autenticación de cliente, es decir, el protocolo de enlace TLS fallará ya que el MITM no puede proporcionar el certificado de cliente esperado.

Solo, los certificados de cliente rara vez se usan. Además, un protocolo de enlace TLS fallido no significaría que el cliente puede comunicarse con el servidor sin intercepción SSL, sino que el cliente no puede comunicarse con el servidor en absoluto. Una forma alternativa sería utilizar algunas heurísticas para detectar el tipo de cliente TLS basado en la huella digital del protocolo de enlace TLS, es decir, el tipo y el orden de los cifrados, el uso de extensiones específicas ... Mientras que un proxy de interceptación SSL podría emular en teoría el original ClientHola perfectamente, la mayoría no. Consulte también Detectar man-in-the-middle en el lado del servidor para HTTPS o la sección III Heurística de implementación de TLS en El impacto de seguridad de la intercepción HTTPS .

— Steffen Ullrich
fuente

14

Para mí, parece que el empleador utiliza su posición superior para espiar el tráfico SSL del empleado. Para mí, esto hace que todo el concepto de SSL no sea confiable

El problema no está en el concepto de SSL ni en la implementación técnica, sino que alguien más tiene control total sobre un punto final de la conexión, es decir, su estación de trabajo.
Esa es la raíz del riesgo de seguridad real ...

Desde una perspectiva de seguridad, es su estación de trabajo la que se ve comprometida, lo que rompe la cadena de confianza que, en circunstancias normales, impide que un MITM tenga éxito.

¿Cómo puedo validar la cadena de confianza en el lado del servidor?

No puedes Eso se hace del lado del cliente.

Dependiendo de su caso de uso, lo que puede hacer es RFC 7469 HTTP Public Key Pinning en el que envió un encabezado adicional al cliente con una lista (hash) de sus certificados SSL reales o las CA que utiliza.

— HBruijn
fuente

44

HPKP no ayudará, ya que los navegadores lo ignorarán si el certificado está firmado por una CA agregada explícitamente. Esto se hace específicamente para permitir la intercepción de SSL por parte de una parte confiable, es decir, un firewall corporativo o un AV de escritorio local (muchos interceptan SSL).

— Steffen Ullrich

2

Tiene toda la razón: §2.6 del RFC: "Es aceptable permitir que la Validación de PIN se deshabilite para algunos hosts de acuerdo con la política local. Por ejemplo, un UA puede deshabilitar la Validación de Pin para los hosts pinned cuya cadena de certificados validada termina en "un ancla de confianza definida por el usuario, en lugar de un ancla de confianza integrada en la UA (o plataforma subyacente)".

— HBruijn

3

Ese es el camino equivocado. No el servidor comprueba la cadena de confianza. Es el cliente. Entonces, la razón por la cual la compañía usa esta forma es asegurar el entorno de la compañía y verificar lo que el empleado está haciendo en su tiempo de trabajo.

— creyente
fuente

Bueno, sí, soy consciente de que esto probablemente no se puede evitar solo en el lado del servidor. Sin embargo, algunos JS del lado del cliente también pueden ser engañados. Por cierto, espiar a los empleados es ilegal en la mayoría de los países europeos. Como operador de un sitio web, quiero evitar que engañen a mis clientes, por lo tanto, me pregunto si hay alguna forma de validar la cadena de confianza de manera segura.

— Aileron79

Tal vez no está permitido. Pero la mayoría de las empresas no espían a los empleados, que solo quieren proteger su red, y la mayoría de los filtros web o escáneres deben interrumpir la conexión SSL para verificar esto. Así que este es un hombre legal en el ataque del medio

— cree el

Entiendo tu punto. Sin embargo, esta pregunta es sobre cómo puedo asegurarme de que una conexión HTTPS esté encriptada de extremo a extremo. La configuración que describí anteriormente es muy común en entornos corporativos, pero el mismo tipo de ataque podría ser utilizado por chicos celosos para espiar a sus novias o por los propietarios que interceptan el tráfico de sus inquilinos. Todavía es necesario engañar a estas personas para que instalen un certificado, pero esa es la parte fácil. Sin embargo, esto es ilegal, y todavía me pregunto si hay alguna manera de asegurarme de que una conexión HTTPS realmente esté encriptada e2e.

— Aileron79

3

Eso no es posible. Cuando el certificado raíz se ha cambiado en el cliente, no tiene forma de verificarlo. El servidor no realiza la comprobación, el cliente realiza la comprobación.

— beli3ver

3

Usted PODRÍA (tipo de), pero la verdadera pregunta es si usted DEBE .

Pero cuidado, no es tan simple como cambiar una bandera en apache.conf.

Además, como el "atacante" (por ejemplo, el empleador) controla la computadora del cliente, siempre puede frustrar sus intentos si está dispuesto a invertir suficiente esfuerzo (por el lado positivo, a menos que sea un pez muy grande, lo más probable es que no inclinado, para que logre su objetivo de que sus usuarios no puedan conectarse con usted a menos que sea seguro))

puede volver a implementar TLS en javascript y verificar allí si el certificado de que el cliente está conectado es el certificado de su sitio web.
si tiene suerte , el usuario podría estar usando un navegador donde Javascript del lado del cliente puede obtener información sobre el certificado remoto utilizado (y así verificarlo fácilmente contra el valor codificado del certificado de su servidor).
podría usar JavaScript para ejecutar su cifrado personalizado . Entonces, incluso cuando el malvado TLS MiTM de la compañía tuvo éxito, todavía no le daría acceso a sus datos. Por supuesto, si hay suficiente interés (y dado que controlan al cliente), podrían reemplazar sobre la marcha su javascript seguro con el suyo, que también registra (o cambia) toda la información en tránsito.

Además, dado que las empresas que emplean proxys TLS MiTM también suelen controlar la computadora del cliente por completo, podrían instalar fácilmente la pantalla y el keylogger para simplemente grabar video de todo lo que ve el usuario y grabar todas las pulsaciones de teclas (y movimientos del mouse) que el usuario escribe. Como puede ver, cuando el atacante ES el cliente, no hay una forma absolutamente segura de engañarlo. Realmente es solo una pregunta cuánto van a molestar ... Y algunas de las soluciones anteriores pueden ser lo suficientemente buenas para usted.

— Matija Nalis
fuente

" podrías reimplementar TLS en javascript " ¿Cómo? ¿Dónde?

— curioso

@curiousguy ese texto enviado es un enlace: haga clic en él y lo llevará a otra pregunta y respuesta, y finalmente al proyecto digitalbazaar / Forge

— Matija Nalis

Entonces, ¿cuándo es utilizable? ¿Para que propósito?

— curioso

@curiousguy entre muchas otras cosas, especialmente para los propósitos que se hacen en esta pregunta de Serverfault. Cuando tiene su propio JS TLS ejecutándose en el cliente, ese cliente JS sabrá exactamente a qué servidor TLS se ha conectado el cliente (y es una clave pública). Luego puede comparar esa clave pública con la clave pública del servidor autorizado (también codificada en su JS), y si sabrá si son las mismas. Si no son iguales, MiTM ha secuestrado su conexión.

— Matija Nalis