La mejor manera de buscar y eliminar versiones anteriores de SSL / TLS en un entorno de producción

@atdre apunta a una herramienta que debería permitir detectar si un servidor dado admite TLS 1.2, pero esto es solo una parte de la historia. En SSL / TLS, los pasos iniciales de una conexión son el handshake en el que se acuerdan una serie de parámetros entre el cliente y el servidor, incluida la versión del protocolo que se usará. El cliente anuncia la versión de protocolo más alta que admite, luego el servidor elige la versión que se usará (normalmente, la versión más alta que el servidor conoce, pero no más alta que la versión máxima anunciada por el cliente).

Por lo tanto, incluso si todos sus servidores están listos para usar TLS 1.2, esto no necesariamente implica que solo se usará TLS 1.2; depende de lo que aceptarían los servidores además de TLS 1.2 y de lo que admiten los clientes . Para un servidor determinado, tiene básicamente dos métodos para asegurarse de que se utilizará TLS 1.2:

1. Asegúrese de que el servidor admita solo TLS 1.2: si un cliente anuncia "TLS 1.1" como versión más alta, el servidor debe rechazarlo. Si un servidor acepta solo TLS 1.2, solo se utilizará TLS 1.2 al hablar con este servidor.

2. Verifique que todos los clientes que hablan con el servidor anuncien TLS 1.2 como la versión más alta, y el servidor acepte. Básicamente, esto implica ejecutar una herramienta de monitoreo de red (por ejemplo, Wireshark ) para observar los mensajes ClientHello realmente enviados por los clientes y el ServerHello mensajes enviados en respuesta.

Otras complicaciones provienen del comportamiento de "degradación automática" de algunos clientes (generalmente navegadores web). El cliente puede intentar conectarse, primero, enviando un ClientHello que dice "Admito hasta TLS 1.2". Sin embargo, si eso falla, el cliente puede pensar que el servidor puede ser alérgico a TLS 1.2; se sabe que todavía hay algunos servidores web implementados que no siguen la especificación correctamente, y simplemente descartan las conexiones cuando ven "TLS 1.2 "porque no lo entienden. Para dar soporte a estos servidores mal implementados, algunos clientes SSL / TLS, en caso de falla de reconocimiento, lo intentarán de nuevo, esta vez con un ClientHello que anuncia "Admito hasta TLS 1.0".

Desafortunadamente (para su situación actual), esto significa que aunque un cliente y un servidor parecen usar TLS 1.2 en condiciones normales, un atacante activo puede romper bruscamente las conexiones que comienzan con un protocolo de enlace TLS 1.2 (el atacante activo inyecta RST falsos paquetes para matar la conexión TCP subyacente). En tal situación, el atacante puede activar el mecanismo de degradación automática y obligar al cliente y al servidor a usar una versión inferior.

Entonces, si realmente quieres asegurarte de que solo se use TLS 1.2, incluso en presencia de un atacante astuto, solo se aplicará el primer método. En otras palabras, utilizando sslyze o cualquier otra herramienta similar, debe asegurarse de que cuando un cliente solicite TLS 1.2, obtenga TLS 1.2, y también que si un cliente solicite TLS 1.1, el servidor lo rechace.

La evaluación activa de todas las direcciones IP y nombres de host conocidos es el mejor método para auditar una infraestructura para su total cumplimiento.

sslyze --sslv2 --sslv3 --tlsv1 --tlsv1_1 --targets_in=target-list.txt --xml_out=sslyze.xml

Puede obtener sslyze aquí - enlace

También es posible que necesites un desarrollador que entienda el análisis XML para ordenar mejor los resultados.

¿Qué quiere decir con "hay una manera de automatizar ... en lugar de ir a través de una lista"? ¿La automatización no requeriría una lista?

Puedo pensar en dos formas posibles de realizar una prueba sin conectarme a cada servidor. Una sería usar una configuración estándar de oro y verificarla con una herramienta como Lynis. Puede ver una secuencia de comandos que verificará las configuraciones de los servidores web (incluida una comprobación detallada de SSL / TLS para nginx) aquí: enlace

La última forma de detectar servicios en su entorno que ejecutan versiones SSL / TLS no compatibles sería utilizar una infraestructura de captura de paquetes. Existen numerosas formas de configurar su entorno para las evaluaciones de captura de red, y no las veré aquí. Sin embargo, he visto algunas herramientas que verifican los encabezados del servidor (que pueden proporcionar una biblioteca de SSL / TLS o la versión del módulo) y / o los protocolos mismos. En la categoría anterior: snort, prads y tshark pueden ser excelentes maneras de interactuar con interfaces de captura en vivo y / o datos de pcap almacenados. En la última categoría: ssldump y pyshark se pueden hacer para proporcionar información de protocolo detallada. Sin embargo, ambas técnicas solo podrán mostrar los servicios SSL / TLS que están en uso; no mostrarán servicios inactivos SSL / TLS que no estén en uso o que no se usen con frecuencia. Otra gran victoria aquí es tls-fingerprinting (por ejemplo, huellas digitales) y está asociada snort rules .