Normalmente, cuando se realiza HTTPS a través de un proxy, esto se hace con el mecanismo CONNECT : el el cliente habla con el proxy y le pide que proporcione un túnel bidireccional para bytes con el sistema de destino. En ese caso, el certificado que el cliente ve es realmente del servidor, no del proxy. En esa situación, el proxy se mantiene fuera de la sesión SSL / TLS; puede ver que se está ejecutando algo de SSL / TLS, pero no tiene acceso a las claves de cifrado.
Algunas organizaciones implementan un completo Man-in-the-Middle generando un certificado falso para el servidor de destino sobre la marcha. Lo hacen precisamente para que el proxy pueda ver los datos de texto sin cifrar y escanearlos para cumplir con la política de la organización (por ejemplo, análisis antivirus automático). Esto solo puede funcionar si el cliente (su navegador) acepta el certificado falso como genuino, lo que a su vez requiere que se inserte una CA raíz controlada por la organización en la máquina cliente (y en un mundo de Windows / Active Directory, un GPO puede hacerlo). que).
Acerca de los principales proveedores de firewall / dispositivos proxy que ofrecen ese mecanismo como opción.
No todas las organizaciones implementan un sistema MitM de este tipo, por varias razones, entre ellas:
-
La MitM automática puede ser costosa. El dispositivo proxy puede tener que ser computacionalmente poderoso si hay muchos usuarios; y la licencia del producto puede ser alta.
-
MitM rompe la autenticación del cliente basada en certificados.
-
Hacer un MitM solo tiene sentido si realmente inspeccionas los datos, lo que a su vez aumenta los costos computacionales.
-
El empuje automático de una CA raíz no funciona con BYOD .
-
Como regla, a los usuarios realmente les disgustan tales MitM.