Las mejores opciones para la inspección SSL mientras se mantiene el perfecto secreto hacia adelante

0

Estamos buscando monitorear las conexiones HTTPS entrantes para detectar problemas de rendimiento y errores. Las solicitudes HTTP son capaces de recopilar esta información muy bien, pero no tenemos una manera de hacerlo manteniendo el PFS a través de HTTPS. Nuestra herramienta de descifrado HTTPS no admite cifrados DH en absoluto, por ejemplo.

¿Qué hacen las personas para esto?

    
pregunta user3408592 17.04.2017 - 22:18
fuente

3 respuestas

1

Por lo que desea hacer un análisis sobre el tráfico HTTPS entrante. Una forma común es usar proxies inversos (comúnmente Apache o nginx) frente a los servidores reales, instalar los certificados de servidor en los proxies inversos y hacer el descifrado SSL / TLS en los proxies. Da:

client <-> Internet <-> [ router <-> { reverse proxies <-> actual servers } ]
                        |            |
                   corporate      security
                    network         zone
                     limit         limit

En este escenario, los servidores proxy inversos estarán en la misma zona de seguridad que los servidores, lo que significa que solo los administradores deben poder detectarlos y el tráfico entre los servidores proxy y los servidores. Por lo tanto, el tráfico entre los servidores proxy y el servidor se puede descifrar de forma segura (pero debe transportar certificados de cliente opcionales). Como los proxies inversos son normalmente más simples que los servidores de aplicaciones, es más fácil agregar filtros y análisis de tráfico allí.

    
respondido por el Serge Ballesta 25.07.2017 - 09:50
fuente
0

Esta es una pregunta realmente interesante porque cuando crypto usa Perfect Forward Secrecy , como TLS 1.2 con DH está en juego, luego se rompen las herramientas que intentan realizar el trabajo del hombre en el medio para inspeccionar el tráfico.

Inspeccionar el tráfico haciendo que el navegador escriba las claves en un registro

Hay algunas cosas que puedes hacer. Debes mirar algo llamado SSLKEYLOGFILE. El tutorial completo está cubierto en muy buena profundidad aquí,   descifrando el tráfico del navegador TLS con conexiones de cables de forma fácil , pero esencialmente, puede exportar una variable de entorno llamada SSLKEYLOGFILE y señalarla a un archivo. La próxima vez que se inicie Firefox o Chrome, buscarán esta variable y, si existe, comenzarán a escribir todas las teclas CLIENT_RANDOM y las teclas DSA en el archivo mientras el usuario navega.

Wireshark puede tomar el SSLKEYLOGFILE y usarlo para descifrar los paquetes TLS e inspeccionar el tráfico.

El registro de claves TLS está en el cliente

Notará que toda esta escritura de clave TLS / SSL ocurre en el lado del cliente. Podría hacer que todos sus clientes comiencen a escribir sus claves en un recurso compartido de archivos, recopilar su tráfico e inspeccionarlo. Esto no sería en tiempo real, y no funcionaría para todos los programas, pero soluciona su problema de no poder inspeccionar el tráfico que usa
DH .

    
respondido por el Nik Roby 18.04.2017 - 15:16
fuente
0

Así que quieres espiar algunos PFS:

Así que hay algunas maneras diferentes de hacer esto. Pero algunas de las cosas que está pidiendo necesitan más de la imagen para discernir. Veremos el que está proponiendo: inspeccionar.

Rompe e inspecciona

La ruptura y la inspección requieren que podamos abrir el TLS, y los cifrados EC (DH) están diseñados para ser resistentes al MITM. Hace un tiempo hubo una gran publicación que revisó las limitaciones ( Descifrando TLS en Wireshark al usar conjuntos de cifrado DHE_RSA .) Tl; dr, necesita las claves pre-maestras de su aplicación y una forma de consumirlas.

Otra forma de romper e inspeccionar es mover el punto de terminación TLS a un dispositivo que puede instrumentar (un proxy de apache / nginx de algún tipo). Si tiene otras solicitudes de proxy de dispositivos en su nombre, puede inspeccionar eso. Tráfico a través de la aplicación del proxy.

Pregunte al servidor

Finalmente, la forma en que intentaría hacer esto es: buscaría en el servidor web. Casi toda la información que mencionó (4XXs, registros de URI, tiempos de espera de sesión de TCP, etc.) se puede obtener de los registros del servidor web.

Locura

Si tenemos que realizar esta actividad sin interrupciones e inspeccionar, o acceder a los registros del servidor web, y no tuve fin de tiempo, podría intentar y ( enlace ) implemente un ataque práctico de Bicycle ya que tengo acceso al texto sin cifrar para cosas como 404 páginas, etc. No podría obtener información significativa sobre los errores, solo confianza que hubo errores, etc. Cualquier tipo de inspección de red capturará las desconexiones del nivel de TCP / IP, etc. pero todavía estará limitado a lo que realmente puede ver.

    
respondido por el Ori 19.04.2017 - 16:28
fuente

Lea otras preguntas en las etiquetas