¿En qué se diferencia el túnel SSH a través de Proxytunnel / HTTPS de hacerlo a través de SSL con Stunnel?

TL; DR : creo que su problema no está relacionado con SSL en absoluto, pero está intentando usar un servidor proxy sin los encabezados proxy.

  

Entonces, si uso stunnel para crear un túnel SSL y luego paso el tráfico HTTP a través de él, ¿sería lo mismo que usar HTTPS normalmente?

Sí. Usamos http over stunnel en el trabajo para hablar con un servidor https. Esa es una solución para un error en el cliente Java https que no puede comunicarse con un servidor https ISS en algunas situaciones.

  

Luego, si un proxy / firewall solo ve una conexión SSL / TLS con tráfico cifrado, ¿cómo podría saber que el tráfico no es HTTP?

Un proxy / firewall normal no puede decir lo que hay dentro.

Hay descifrado https-proxies . Para que funcionen, necesitan engañar al cliente para que acepte su propia clave pública en lugar de la clave pública del servidor real. En https, la clave pública es parte de un certificado que contiene información sobre el nombre del servidor. Los certificados suelen estar firmados por entidades emisoras de certificados, que los navegadores consideran confiables.

El servidor proxy debe falsificar el certificado del servidor para que el cliente utilice su propia clave pública. Un cliente normal mostrará una advertencia sobre el certificado no válido. Pero el proxy puede firmar los certificados falsificados con su propia CA. Y el administrador de puede instalar el CA confía en los clientes .

  

En teoría, creo que si el proxy / firewall no nota la diferencia, uno debería poder canalizar el tráfico SSH a través de una conexión SSL / TLS (creada con stunnel) en lugar de HTTP.

La forma común de hacer un túnel de SSH incluso funciona sin la capa SSL en servidores https no descifrados.

  

Sin embargo, en la práctica, he visto que esto no funciona: el proxy / firewall parece capaz de detectar que no es tráfico HTTPS.

O estás haciendo algo mal, o estás detrás de un https de descifrado como se explicó anteriormente.

  

Creo que esta es la razón por la que se usa Proxytunnel, pero no entiendo qué hace Proxytunnel de manera diferente para evitar la detección. ¿Simplemente crea encabezados HTTP falsos?

Debe distinguir entre un firewall y un proxy aquí: si solo hay un firewall de red, puede conectarse a la dirección IP de destino en el puerto 443 normalmente. Pero si hay un proxy, necesita conectarse a la dirección IP y al puerto del proxy y luego decirle que se conecte al destino mediante el protocolo http. El comando es: CONNECT target:port HTTP/1.1 <cr><lf>

En la mayoría de los casos, los servidores proxy https permiten la conexión a cualquier dirección IP, pero solo al puerto 443. Después de enviar la cadena de conexión, obtiene un encabezado de respuesta http. En un proxy https normal, cualquier información adicional se reenvía como está en cualquier dirección. Para que puedas hablar cualquier protocolo que quieras. Usando ssh de forma nativa desde aquí en las obras.

En teoría, un cortafuegos o un proxy tonto pueden evitar este túnel nativo detectando tráfico sin SSL. Pero esto es muy raro. Solo un proxy de descifrado https podrá prevenir este tipo de túnel de manera efectiva.

Si realiza HTTP al puerto del servidor de una instancia de stunnel:

client <--- TCP ---> stunnel <--- TCP ---> server
                             <--- TLS --->
       <------------- HTTP -------------->

será casi exactamente como usar HTTPS, pero no completamente porque el cliente todavía se ve a sí mismo como usando HTTP sobre TCP. Por ejemplo, un navegador no mostrará "Seguro" en la barra de URL, y el código Javascript que se ejecuta en el navegador podría negarse a hacer cosas si la conexión no es HTTPS.

Para el resto de su pregunta, necesita averiguar exactamente qué está pasando con el "firewall" o el "proxy" que está usando; hay varias técnicas diferentes que puede usar para manejar la conexión que le permitirán o evitarán ciertas técnicas cuando la use.

1. Conexión TCP directa

Si está realizando una conexión TCP que termina en el host remoto (diagrama anterior), incluso si se modifica de alguna manera (por ejemplo, las direcciones se modificaron a través de NAT), y configura una conexión TLS en esa conexión TCP, Los enrutadores intermedios no podrán ver el tráfico más allá de su cantidad, las direcciones IP y los puertos TCP, y el hecho de que es TLS. Un servidor de seguridad de nivel IP podría configurarse para no permitir conexiones a puertos distintos de 443 o abandonar las conexiones a 443 si ve que no son TLS. Incluso podría conectarse primero al puerto en sí para ver si el servidor parece estar ejecutando HTTP / TLS en ese puerto.

2. Proxy HTTP CONNECT

Si vas a usar un proxy HTTP utilizando el verbo CONNECT , como Proxytunnel hace, hay dos conexiones TCP involucradas pero usted hace una conexión TLS sobre ellas:

client <---- TCP 1 ----> proxy <---- TCP 2 ----> server
                        CONNECT
      <------------------ TLS ---------------->

Todavía está negociando TLS con el servidor real en el otro extremo, y la situación es bastante parecida a la del # 1 anterior. No es necesario hacer TLS a través de las conexiones TCP, en realidad; simplemente podría CONNECT server.mydom.com:22 y comenzar a hablar SSH a través de esa conexión si el proxy no rechaza esa solicitud. Algunas personas tienen servidores SSH que escuchan en el puerto 443 exactamente para este propósito. Sin embargo, si el proxy es lo suficientemente sofisticado como para verificar el protocolo en uso, puede desconectarlo si ve que no realizó una configuración estándar de TLS, aunque una vez que se haya activado el TLS, no podrá ver exactamente qué sucede en esa conexión. .

3. MITM

Algunas organizaciones realizan ataques de intermediario en las conexiones HTTPS (a veces más educadamente llamadas "intercepción SSL"). Cuando intenta conectarse al servidor remoto, ya sea a través de una conexión TCP directa o un proxy como en cualquiera de los casos anteriores, un dispositivo de red simula que es el servidor remoto.

client <---- TCP 1 ----> MITM <---- TCP 2 ----> server
       <---- TLS 1 ---->      <---- TLS 2 ---->
       <---------------- HTTP ---------------->

Su navegador web intenta la configuración TLS, verifica el certificado y lo validará no porque sea el certificado real, sino porque el dispositivo generó un certificado firmado por una CA privada (autoridad de certificación) y el departamento de TI también modificó Cert lista en el navegador o sistema operativo para confiar en ese CA. (Con frecuencia, puede darse cuenta de que esto está sucediendo al intentar la misma conexión con otro programa que usa una lista de certificados diferente sin ese certificado, como Firefox si lo descarga de forma independiente). Tiene una conexión segura con el dispositivo MITM, pero lo está descifrando todo. y volver a cifrarlo para otra conexión segura separada al servidor cuando reenvía datos.

En este caso, aunque cree que está hablando con el servidor remoto, en realidad está hablando de manera segura solo con el proxy que tiene acceso completo a todos los datos de la conexión y puede verlo y modificarlo como desee.