¿Cuáles son los riesgos asociados con la interceptación de SSL en una organización?

Comprometer a su CA raíz o intermedia será más fácil que comprometer a una CA comercial, por lo que disminuye el costo de montar un ataque no detectable para el usuario en las conexiones HTTPS cuando sus empleados están conectados directamente a Internet (ej. cafetería wifi). No veo esto como una amenaza muy grande.

Existe un riesgo evidente para los usuarios de un servidor proxy / sysadmin / servidor proxy malicioso: el atacante ahora puede interceptar y robar todas sus redes sociales personales / correo electrónico / credenciales bancarias.

Operativamente, esto ha causado problemas para los certificados raíz que no están en el almacén de confianza del servidor proxy. Esto es común si el administrador de la red no está al día con los parches en el dispositivo, o si el dispositivo está desactualizado (vea Bluecoat).

Me he dado cuenta de que los servidores que usan un proxy HTTPS tienen varios problemas, especialmente si el proxy es un proxy de los equipos de red, por ejemplo, balanceadores de carga, etc. Para este fin, inhabilitamos el proxy de servidores.

Finalmente, puede haber problemas al implementar la infraestructura de CA internamente y hacer que esté altamente disponible. La CRL debe estar disponible a través de HTTP (no HTTPS), y OCSP debe configurarse correctamente.

Si la CRL no se actualiza con la frecuencia suficiente (como se especifica en next update ), es posible que algunos clientes internos rechacen el certificado basándose en la premisa de que no pueden probar que se ha revocado.

Finalmente, el certificado raíz debe estar en todas las tiendas locales aplicables. Por ejemplo, Java, Firefox, IE / Windows tienen diferentes tiendas que necesitan actualizarse. La implementación de un certificado no es tan simple como implementarlo a través de GPO.

También considere sus dispositivos que no son AD, como Macs, iPhones, dispositivos móviles que no son administrados centralmente (BYOD) al implementar este certificado raíz.

Línea inferior

Las complejidades involucradas en la implementación de un proxy SSL centralizado pueden crear agujeros en su política de seguridad que son inesperados y / o no se mantienen.

Debe existir una solución integral para mantener, eximir o prohibir componentes incompatibles que no se ajusten a la política de seguridad. Esto debe hacerse lo más simple posible.

e.g. Exempt servers, and mobile devices on wifi.  Everything on corpnet as a workstation must be proxied.

Los riesgos son casi los mismos que los que implica dar a un guardia de seguridad designado una llave que abre todas las puertas de un edificio:

• El guardia se convierte en un objetivo valioso; los atacantes querrán robar a la guardia o sobornar a la guardia para obtener la llave de oro.

• Al abarcar todo, la clave omite todos los procedimientos y capas de seguridad; no puede aislar partes del edificio entre sí, si el atacante potencial tiene una llave que abre todas las puertas.

• El conocimiento de la mera existencia de una llave de abrir todo en manos de algún guardia de seguridad hará que los usuarios sean bastante desconfiados. Los usuarios humanos tienden a valorar su privacidad y no les gusta la idea de que alguien abrirá rutinariamente sus escritorios y casilleros e inspeccione el contenido.

Más allá de la analogía clave, mediante la intercepción SSL (con una CA específica de la organización utilizada para construir ataques MitM sobre la marcha) tiene las siguientes consecuencias específicas:

• En los sistemas de escritorio, la intercepción requiere la instalación del certificado de CA especial en el "almacén de confianza". Esta instalación debe hacerse de nuevo cada vez que se instale un nuevo sistema operativo; los usuarios pueden eliminarlo ellos mismos; algunos navegadores web (en particular Firefox) ignorarán el almacén de confianza del sistema operativo y utilizarán el suyo propio. Por lo tanto, hay un amplio espacio para la rotura aquí. Esto se puede solucionar de alguna manera bloqueando la configuración del sistema operativo y la instalación del software, pero cuanto más bloquee las cosas, menos felices estarán los usuarios.

• El almacén de confianza del sistema operativo se puede usar para otros usos que no sean simples SSL; se puede utilizar para verificar firmas en actualizaciones de software y controladores, por ejemplo. Un atacante que logra robar la clave privada de la organización CA puede obtener un gran poder en toda la red, no solo la capacidad de interceptar conexiones SSL (que ya son muchas).

• La clave privada para la entidad emisora de certificados es, por lo tanto, sensible, pero no puede ser protegida con capas de alto aislamiento, porque esa entidad emisora de certificados especial, por construcción, debe ser capaz de emitir certificados de servidor SSL falsos sobre la marcha. Por lo tanto, debe estar en línea, en un servidor que esté "cerca de Internet".

• Dicha intercepción MitM rompe la autenticación del cliente basada en certificados. Los sitios web https:// rara vez usan certificados de clientes, pero algunos bancos lo han hecho para autenticar a sus clientes (al menos como parte de implementaciones experimentales).

• En muchas jurisdicciones, la inspección automática de las comunicaciones del usuario por parte del empleador es legal, pero está sujeta a ciertas condiciones, generalmente una notificación explícita en el contrato del empleado. Puede haber riesgos legales relacionados con dicha intercepción (de manera similar a leer cartas, tocar el teléfono e instalar cámaras de video en oficinas). Se recomienda encarecidamente el desvío a través del departamento legal.

Por lo tanto, podemos decir que si bien la intercepción SSL organizativa permite la inspección de los contenidos descargados de SSL (por lo tanto, se pueden aplicar antivirus y otros filtros en el proxy), también abre nuevas vulnerabilidades. Por lo tanto, la situación de seguridad general podría empeorar con la instalación de dicho sistema.

El principal riesgo que puedo ver es el peligro del propio servidor proxy. Esto permitirá al atacante descifrar todo el tráfico que pasa por ese sistema.

Existe el hecho de que esta configuración es incompatible con algún mecanismo de autenticación: cualquier sistema que se base en la autenticación del certificado de cliente SSL no funcionará.

Un problema más amplio es la calidad de la implementación en sí misma: necesita usar una CA raíz privada y una CA intermedia, completa con un mecanismo de revocación adecuado y seguridad estricta en todos los elementos de la CA. Hacer cosas incorrectamente en la etapa de diseño es probable que deje mucho más que su tráfico SSL en juego.

Hice esto el año pasado para un cliente, y cuando ejecuta un análisis de riesgos adecuado, resulta que el compromiso del servidor proxy o la pérdida del certificado de raíz es un riesgo técnico, pero otros riesgos son mayores en la evaluación final. .

Nota: Esto es específico de la ubicación. Fuera de Europa, por ejemplo, es posible que no se aplique el riesgo de privacidad.

1. Privacidad: si su empresa permite (1) el uso privado de Internet, puede tener todo tipo de problemas cuando inspecciona paquetes que los empleados pueden asumir que están protegidos contra tal cosa.
2. Responsabilidad: si algo sucede donde SSL desempeña un papel, por ejemplo. un empleado realiza una transacción en la banca en línea y se produce un ataque exitoso, al abrir la sesión de SSL se coloca en la línea de fuego. Ahora necesitas demostrar que eres inocente. Sin la intercepción de SSL, otra persona tendría que demostrar que usted es culpable.
3. Legal - consulte con su departamento legal. Existen muchas leyes sobre telecomunicaciones e interceptación de las mismas, y algunas de ellas pueden aplicarse a la intercepción SSL. Esto puede depender de los detalles minuciosos y solo un experto legal puede responderlo.
4. Excepciones: cada compañía tiene alguien que puede reclamar una excepción. Puede ser una oficina sindical, un oficial de privacidad de datos, un ejecutivo de alto nivel, miembros de las fusiones y empresas; equipo de adquisición, un médico, siempre hay alguien cuyas comunicaciones están privilegiadas y usted debe verificar con mucho cuidado si puede interceptarlas legalmente sin terminar en un mundo de dolor.
5. Superficie de ataque: otros ya respondieron sobre el riesgo de que su servidor proxy sea pirateado. Solo quiero agregar que hay muchas pruebas y estudios que muestran que muchos de estos servidores proxy SSL están bastante mal protegidos. Encontré informes desde 2004 hasta el 2016 con detalles. No quiero enlazar con ninguno porque no sé cuál de estos proveedores solucionó sus problemas mientras tanto, pero una búsqueda rápida los revelará.
6. Manejo de certificados - también ya explicado. Si ejecuta una PKI o tiene implementados buenos procesos de gestión de certificados y claves, esto debería estar bien. Si no lo hace, esta es una fuente potencial de problemas.

(1) "permitir" en este contexto es esencialmente todo lo que no lo prohíbe estrictamente. Si lo permite con calificaciones (durante los descansos, solo para asuntos urgentes, siempre que no afecte el trabajo, lo que sea), lo permite. Hablé sobre esto con un juez de la corte más alta de mi país, y él tuvo muy claro que ven esto estrictamente binario.