VPNs vulnerables a MiTM porque CUALQUIER certificado pasa

Question

VPNs vulnerables a MiTM porque CUALQUIER certificado pasa

#1 de scuzzy-delta (8 votos)
#2 de BlueCacti (3 votos)

7

Hablé con un administrador de sistemas en un centro de negocios que tenía la intención de realizar básicamente un MiTM (como él lo llamaba) en todas las conexiones de su red porque la gente en su edificio de oficinas está usando VPN y conexiones https para transmitir video, descargar torrents Estos servicios utilizan todo el ancho de banda, pero como son conexiones cifradas, su equilibrador de carga no funciona.

La empresa de seguridad que contrató lo convenció de que es posible configurar un servidor proxy con su propio certificado válido y firmado (por supuesto, para el servidor proxy) que engañaría a todos los navegadores y conexiones VPN para aceptar el proxy como su punto final. Esto le permitiría descifrar todo el tráfico, verificar su contenido y acelerar si fuera necesario, cifrarlo una vez más y enviarlo en la forma prevista sin que nadie sea más sabio.

En la parte de https logré explicarle / convencerlo de que cualquier implementación de https medio decente está diseñada específicamente para evitar los ataques de MiTM porque los certificados están vinculados a un dominio o empresa específica. No hay forma de que su proxy pueda engañar a un navegador para que piense que se está conectando con el sitio web mientras que de hecho se conecta al servidor proxy.

Sin embargo, en lo que respecta a las VPN, está convencido (o, mejor aún, de la empresa de seguridad que contrató para su red) de que muchos servicios o protocolos de VPN aceptarán cualquier certificado firmado por una CA para crear una conexión segura. No se verifica si ese certificado se atribuye o no al servidor al que se está conectando.

Esto me parece muy improbable y al contrario de todo lo que sé sobre conexiones seguras, pero antes de retomar esa discusión, quiero asegurarme de que no me esté perdiendo alguna vulnerabilidad poco conocida en los protocolos VPN de software que muy pocas personas conocen. .

Mi pregunta: ¿es cierto que algunos protocolos VPN o el software VPN solo verifican la validez de un certificado al verificar si está firmado por una CA y no verificará en absoluto si el certificado es de hecho atribuido al servidor que usted se están conectando a?

- edición pequeña - Para especificar por qué debería ser posible: según la empresa de seguridad, un buen número de software VPN aceptará cualquier certificado válido y no verificará si el certificado está realmente vinculado al servidor: se acepta cualquier certificado válido.

tls certificates vpn

pregunta user3244085 15.03.2014 - 20:22

fuente

2 respuestas

3

Es posible que desee leer este artículo en el sitio de Gibson Research Corporation : The “S "Añadido al final de" HTTP "significa SEGURO. (O al menos se suponía que debía hacerlo)

La presencia de la clave ininterrumpida o el icono de candado en el navegador web una vez significó que la conexión entre el usuario y el servidor web remoto fue autenticada, segura y encriptada. . . y no es susceptible a ninguna forma de espionaje por parte de terceros. Lamentablemente, eso ya no es siempre cierto.

Y

¿Cómo es este elegante sistema [cfr. Sistema CA] subvertido?

Cualquier corporación, institución educativa u otro proveedor de conectividad de Internet que desee monitorear cada acción de Internet de sus empleados, estudiantes o usuarios: cada ID de usuario privado y amp; La contraseña de cada red social o sitio bancario que visitan, sus registros médicos, todos los correos electrónicos "seguros". . . TODO: simplemente se encarga de agregar un "Pseudo Certificate Authority" adicional a los navegadores o computadoras de sus usuarios . Es así de simple.

respondido por el BlueCacti 16.03.2014 - 01:01

fuente

Lea otras preguntas en las etiquetas tls certificates vpn

Sitio web: Autenticación de clave precompartida ¿Cuáles son los buenos métodos de seguridad visual?

score 8 · Accepted Answer

Respuesta corta:

No, no se puede hacer. Esto se debe a que una Autoridad de certificación acreditada no emitirá un certificado para un dominio que su administrador de sistemas no controla.

Respuesta larga:

Se puede hacer en algunos escenarios.

Por ejemplo, si está utilizando OpenVPN para crear una conexión TLS con un concentrador VPN en otro lugar del mundo llamado ... digamos ... awesomevpn.sx, uno de los primeros pasos en TLS handshake es la validación del certificado del servidor. Su administrador de sistemas podría intentar MITM esta conexión, pero él no podría presentar un certificado para awesomevpn.sx porque ninguna CA lo emitirá , lo que provocaría que la conexión fallara.

Sin embargo, considere un escenario en el que una empresa ha contratado a un proveedor para instalar dispositivos de inspección de paquetes. Para realizar ataques MITM en conexiones seguras, los proveedores obligarán a la instalación de sus propios certificados "raíz" en las máquinas cliente . De esa manera, pueden usar su propia CA para firmar certificados para cualquier dominio. Esto se puede hacer sobre la marcha por los aparatos de inspección. Cuando esos certificados se presenten al cliente durante la secuencia MITM, se aceptarán, lo que permitirá que la conexión se complete y que los paquetes se inspeccionen de forma clara.

Esto suena como una debilidad del sistema de CA, pero recuerde que en un entorno corporativo, no tiene control físico sobre las máquinas que son propiedad de la compañía. Sin control físico, se acabó el juego en términos de seguridad.

Por lo tanto, la explicación que le han dado carece de un punto clave: no mencionaron el requisito de instalar sus propios certificados raíz en las máquinas cliente. No tiene nada que ver con una debilidad en los clientes VPN, o los diversos protocolos utilizados para las conexiones seguras.