Como @aus lo indica, puede intentar observar las características exactas de ClientHello y otras características SSL (por ejemplo, cómo se dividen los mensajes en los registros) para obtener alguna indicación sobre si el cliente es un navegador web genuino o no. . Sin embargo, esto no es robusto:
- Los diferentes navegadores actúan de manera diferente en esa materia. Es posible que esté participando en una búsqueda cuesta arriba sin fin, con una evaluación continua de todas las versiones principales del navegador.
- Una actualización del sistema operativo / navegador puede cambiar sus patrones de uso (por ejemplo, un conjunto de cifrado se habilita de manera predeterminada), por lo que su mecanismo de detección puede estar plagado de oleadas de falsos positivos en algunos momentos impredecibles (cuando Microsoft / Mozilla / Google decide presionar alguna actualización técnica).
- Si los usuarios son conscientes de tales huellas dactilares, entonces pueden comenzar a utilizar clientes que imitan las funciones que está intentando detectar. Es posible la emulación "perfecta" de las características SSL de un "Internet Explorer normal". Proporcionar un incentivo (un mecanismo de detección que desencadene represalias) y ocurrirá.
Es posible que desee realizar un análisis de tráfico en función del tiempo y el tamaño de las solicitudes; cuando un navegador se conecta a un servidor, primero enviará una solicitud con un encabezado cuyo tamaño depende de muchas cosas, pero no será demasiado pequeño. En el caso específico de SSH-within-SSL, hay una manera ingeniosa y simple de utilizar la distinción: agregar un retraso .
Específicamente, cuando un servidor web recibe una conexión, espera: se supone que el cliente envía una solicitud. Desde el exterior, observa un protocolo de enlace SSL, que culmina con los dos mensajes Finished (aparecerían como "protocolo de enlace cifrado" ya que está monitoreando desde el exterior), luego el cliente enviará un registro de "datos de aplicación" (en SSL, el contenido del registro está cifrado, pero el tipo del registro no lo está: es handshake , alert , change_cipher_spec , o datos de aplicación ). Mientras no se envíen los "datos de la aplicación" del cliente, el servidor esperará.
Con SSH, sin embargo, las cosas son diferentes. Tan pronto como se establece la conexión, el cliente y el servidor se envían mutuamente su "banner" (que indica la versión del protocolo, etc.), sin ningún orden en particular. Por lo tanto, cuando su herramienta de monitoreo ve un nuevo protocolo de enlace SSL, puede retrasar temporalmente el primer registro de datos de la aplicación del cliente (por ejemplo, 0,5 segundos), para ver si el servidor enviaría espontáneamente un " Datos de aplicación "registro propio sin esperar el registro del cliente. Si el servidor lo hace, entonces no está hablando HTTP dentro del túnel SSL.
Por supuesto, si comienza a implementar dicho mecanismo de detección, los usuarios se adaptarán, modificando sus clientes y servidores SSH para que los servidores esperen el anuncio del cliente antes de hablar. Es probable que esto degenere en el mismo tipo de guerra estéril que entre virus y antivirus. Esto es, a largo plazo, agotador.
Además de SSH, su mayor problema serán los proxies web. A saber, el usuario:
- Controla un proxy web externo.
- Ejecuta en esa máquina externa un servidor SSL que simplemente reenvía bytes de datos al proxy web.
- Ejecuta en su máquina local un proceso simple que escucha en el puerto local 3128 y reenvía todos los datos al servidor SSL.
- Configura su navegador para usar "localhost: 3128" como proxy para solicitudes web.
Con esta configuración, toda la navegación web del servidor por parte del usuario se realizará a través de la conexión SSL, fuera del alcance de sus sistemas de monitoreo; y, de manera crucial, todas las solicitudes serán solicitudes HTTP desde un navegador web normal, por lo que no se pueden distinguir de las solicitudes HTTP desde un navegador web normal. Esto finalmente derrota el análisis de tráfico.
La conclusión es que lo que estás tratando de hacer es pelear una guerra que no puedes ganar. Te sugiero que comiences a buscar modelos alternativos. Una forma de verlo es la siguiente: si permite BYOD en su lugar de trabajo, debe confiar empleados por no abusar de ellos, y por imponer buenas prácticas de seguridad en ellos mismos.