¿Cuál es el más vulnerable a los ataques MITM, SSL o SSH?

Con SSH, las cosas se hacen así:

• en la computadora portátil, ejecute ssh -N -D 5000 proxy-machine (donde proxy-machine es el nombre DNS de la máquina "Proxy web");
• configure el navegador para usar el protocolo SOCKS en localhost y el puerto 5000.

Esto es conveniente y se activa en mucho menos de 20 minutos. Sin embargo, tiene las siguientes consecuencias:

• El usuario de la computadora portátil debe ejecutar el comando ssh y mantenerlo en ejecución mientras desee navegar por Internet a través del proxy.
• El comando ssh debe estar instalado en la computadora portátil (es un problema estándar con MacOS X, Linux y todos los sistemas similares a Unix, pero no con Windows).
• La máquina Proxy Web debe ejecutar un servidor SSH.
• El usuario de la computadora portátil debe tener una cuenta en la máquina de Proxy Web (es posible restringir esa cuenta a la configuración de túneles como el que se muestra arriba, pero no es fácil de configurar).

Con SSL, tendría que instalar algún software proxy en el Proxy Web (por ejemplo, squid ) y configurarlo con un Certificado X.509, para que los clientes (la computadora portátil) usen https://proxy-machine:9000/ como URL proxy (el número de puerto se puede cambiar a voluntad, usé 9000 como ejemplo). No hay software para instalar en la computadora portátil; el navegador solo tiene que estar configurado para usar la URL correcta como un proxy de nivel HTTP. Desconfíe de los scripts de configuración automática del proxy, podrían ser formas para que el atacante fuerce otra configuración de proxy; Será mejor que configures el proxy manualmente.

SSL y SSH usan distintas protecciones contra los ataques Man-in-the-Middle. El cliente SSH registra la clave pública de la máquina de destino (en el archivo $HOME/.ssh/known_hosts en sistemas similares a Unix) para que pueda verificar que la clave pública del servidor es la correcta; Solo la primera conexión es vulnerable. Las claves públicas de SSH tienen huellas digitales (es decir, valores hash) que se pueden usar para verificar que una clave es correcta (la idea es que puede llamar al administrador del sistema, y él deletreará la huella digital; esto es tedioso pero debe hacerse solo una vez por servidor SSH). Hasta que la computadora portátil o el proxy se vean comprometidos, o los algoritmos criptográficos sean demolidos por los criptoanalistas furiosos, la forma SSH es segura.

SSL se basa en certificados X.509 . La seguridad proviene del conjunto de anclajes de confianza (también conocidos como "certificados raíz") que ya están incorporados en el navegador (o el sistema operativo). Se supone que las autoridades de certificación deben emitir certificados solo a entidades debidamente autenticadas, y las firmas digitales son las herramientas criptográficas mediante las cuales el navegador puede verificar que los contenidos de los certificados no han sido manipulados, y solo las autoridades de certificación aceptadas han participado. Para montar un MitM, un atacante tendría que sobornar a una CA para que emita un certificado falso, con el nombre proxy-machine , pero con una clave pública de propiedad del atacante.

La seguridad X.509 se basa en muchas más suposiciones que la seguridad SSH, que se maneja localmente y donde lo que sucede es bastante simple. Pero el escenario de SSH requiere que el usuario de la computadora portátil esté un poco más consciente de lo que está sucediendo. Para yo , usaría SSH (de hecho, eso es lo que hago); para una organización con muchos usuarios, seguiría la ruta SSL (pero el requisito de "20 minutos" sería una broma).

Mis dos centavos:

• Ambos requerirán clientes / servidores actualizados
• Ambos confían en conocer la huella digital pública de la clave / certificado del servidor.

Para evitar MITM, encuentre una manera de tener la huella digital disponible en el host de su cliente. Con SSH es fácil de lograr ya que almacena la clave y se negará a conectarse al servidor si ha cambiado, hágalo bien una vez y está bien.

El uso de este comando reducirá la probabilidad de un MITM exitoso:

ssh -o VisualHostKey=yes -2

Un punto más para usar SSH, la implementación principal proviene de openssh-server, distribuido por el proyecto OpenSSH . Lo diseñaron e implementaron, se sabe que auditan su código y hacen que cada versión sea más segura.

Ahora, SSL proporcionará menos control que SSH, el navegador a menudo implementa la comprobación de huellas dactilares de forma fácil para el usuario y confía en una cadena de confianza para autenticar certificados / sitios.

Si tiene la opción, SSH es menos vulnerable a MITM:

• no externaliza la confianza
• es fácil verificar los cambios de clave / certificado

La única razón para usar SSL desde mi punto de vista es proporcionar una manera fácil para que los usuarios obtengan criptografía asimétrica para su flujo de datos y, por supuesto, para la autenticación. La usabilidad siempre sacrificará la seguridad en algún momento. SSH se enfoca menos en la usabilidad y más en la seguridad. Es fácil comprender que un acceso de shell en una máquina es más importante que prevenir las escuchas ilegales para el tráfico web. Para los técnicos, debería ser fácil de usar SSH, pero requiere que obtenga un acceso en una máquina rebotadora si desea usarlo en un escenario proxy, mientras que con SSL, ya hay muchos proxies gratuitos, es más conveniente. / p>     

Personalmente usaría SSH por los siguientes motivos.

1. Ya tengo cuentas en algunas máquinas con SSH habilitado
2. Ya he iniciado sesión en esas cuentas, por lo que ya tengo sus claves públicas en caché (efectivamente evitará un ataque MitM)
3. Es un solo comando para configurar la conexión (ver la respuesta de Thomas) y un simple cambio en el navegador (que incluso se puede hacer a través de la línea de comandos con --proxy-server =: en Chrome)

El mecanismo para un ataque MITM sería exactamente el mismo para ambos protocolos, al igual que las técnicas de mitigación. En ambos casos, confía en verificar las diferencias en la clave / certificado del host al conectarse.

Sin embargo, confiaría más en SSH en este caso, ya que SSL se basa en el SSL PKI global (autoridades de certificación, etc.), mientras que SSH simplemente espera que la clave del host nunca cambie. Entonces, mientras que SSH es muy vulnerable a los ataques MITM por la primera conexión, detectará de manera confiable cualquier intento MITM por cualquier conexión subsiguiente, ya que se rastreará la última clave de host confiable y se realizará una comparación en cada conexión intento posterior.

Y si bien es poco probable que un atacante pueda obtener un certificado SSL válido para su nombre de host y poder usarlo en su contra, no es desconocido y a veces sucede.

Además de las respuestas anteriores. Generalmente, HTTPS no se filtra, es más probable que sea SSH en un puerto no estándar, lo que hace que la solución HTTPS sea utilizable en más casos.

Además, con las extensiones del navegador como Certificate Patrol puede recibir avisos de cambios en la clave del servidor como SSH y no estar a la merced de una autoridad de certificados corrupta o incompetente.