Por qué SSH no necesita la capa de TLS

Tu firewall corporativo lleva semanas bloqueando intentos de conexión por el puerto 22. Alguien del equipo sugiere enmascarar el tráfico envolviendo SSH sobre TLS para colarlo por el 443 y «ser más seguros». Suena a un parche ingenioso. Hasta que miras la latencia de la conexión y el uso de CPU del servidor.

La idea de apilar protocolos de seguridad suena bien sobre el papel, pero la práctica es otra. SSH sobre TLS es redundante por definición. Es como comprar una caja fuerte de titanio para guardar dentro otra caja fuerte que ya tenías. Si el protocolo de origen ya hace el trabajo, añadir capas extra no es defensa en profundidad. Es ineficiencia diseñada.

#Arquitectura de SSH vs TLS: El problema de las capas

SSH ya es un protocolo de red seguro por sí mismo. Define su propio handshake, negociación criptográfica y autenticación. Si le añades TLS por debajo, estás duplicando todo el proceso. El RFC 4251, que define la arquitectura de SSH, deja claro que su diseño contempla la confidencialidad e integridad del canal desde el primer byte.

TLS (definido en el RFC 8446 para su versión 1.3) hace exactamente lo mismo, pero está pensado para flujos de aplicaciones genéricas como HTTP o SMTP. Ponerlos en serie no añade seguridad. Añade complejidad.

Doble handshake. Doble negociación de claves. Doble CPU quemada en operaciones criptográficas para transmitir un mismo paquete. No tiene sentido a nivel de ingeniería mantener dos túneles paralelos cuando el interno ya garantiza la confidencialidad del canal.

#Modelos de confianza: PKI vs TOFU

Aquí es donde el diseño de SSH brilla frente a la web. TLS depende de un modelo PKI (Public Key Infrastructure). Necesitas una Autoridad Certificadora externa que valide tu identidad. Si la CA se compromete, tu conexión segura se va al garete.

SSH usa TOFU o claves fijas. No necesitas pagar a una CA para administrar tu servidor. Es llamativo que el estándar web siga confiando en un oligopolio de empresas para validar algo tan crítico, mientras que para administración de sistemas llevamos décadas auto-gestionando la confianza sin pagar un céntimo y funcionando perfectamente.

Mezclar ambos modelos genera conflictos. ¿Confías en la CA de TLS o en la clave del host de SSH? Si usas SSH sobre TLS, tienes que mantener ambos sistemas de revocación y actualización de claves. Un dolor de cabeza innecesario.

text

SOBRECARGA DE HANDSHAKE (Tiempo de conexión):
SSH puro ██ 1x (Negociación rápida)
TLS 1.3 ██ 1x (Negociación rápida)
SSH+TLS ████ 2x (Doble latencia inicial, doble CPU)

#Multiplexión de canales: Lo que SSH hace mejor

SSH no es solo un túnel ciego para pasar bytes. Permite múltiples canales lógicos (sesiones interactivas, X11, redirección de puertos) sobre una sola conexión TCP. TLS te da un tubo. Si quieres multiplexar sobre TLS, tienes que programarlo tú en la capa de aplicación.

Con SSH, las funciones vienen de fábrica. Esto es vital para sesiones interactivas donde necesitas abrir y cerrar canales sin renegociar el cifrado de la conexión principal.

#Caso real: Tunelizar tráfico por SSH en lugar de TLS

Me encontré este escenario en un cliente con un VPS en Raiola Networks. Tenían un panel de VNC expuesto y querían asegurararlo. Su primera idea fue levantar un stunnel con TLS para cifrar el VNC. Un desastre de certificados. Luego, para «asegurarlo más», pensaron en conectarse al servidor por SSH y luego al túnel TLS.

Lo que saltó a la vista fue la latencia. El ratón en VNC se movía con un retraso absurdo. Mi primera reacción fue echarle la culpa al panel de VNC. Intenté ajustar la compresión y los parámetros de color del escritorio remoto sin éxito.

El error de diagnóstico fue claro. El problema no era el VNC, era la pila de protocolos apilada. Eliminé el stunnel y configuré un túnel SSH directo.

Un solo comando: ssh -L 5901:localhost:5901 usuario@servidor. El VNC pasó por el canal SSH, usando el cifrado nativo de SSH, sin certificados y con menor sobrecarga. Cero latencia añadida por doble cifrado.

#¿Es esta solución para ti?

Usa TLS para lo que fue diseñado: asegurar tráfico web (HTTPS), APIs (REST/GraphQL) y correo electrónico. Su integrencia con navegadores y el modelo de confianza público lo hacen ideal para servicios orientados al usuario.

Usa SSH para administración remota de sistemas, transferencia de archivos (SFTP/SCP) y creación de túneles locales o dinámicos. Su capacidad para manejar sesiones interactivas y autenticación basada en claves sin terceros es insuperable.

#Veredicto: ¿Deberías envolver SSH en TLS?

No. Es un desperdicio de ciclos de CPU. Si tu objetivo es la seguridad, configura correctamente los algoritmos de cifrado en tu sshd_config (usando Ed25519 y descartando RSA y SHA-1) y usa claves de hardware si quieres paranoia. Si tu objetivo es eludir un firewall que bloquea el puerto 22, hay formas mucho más limpias de hacerlo.

#Cómo volver atrás si tu firewall bloquea SSH

Si te encuentras en una red restrictiva (un café con wifi de pago o una corporación con políticas de salida estrictas) y necesitas salir por el puerto 443, no uses TLS. Usa multiplexación de puertos.

La herramienta estándar para esto es sslh. Es un multiplexor que escucha en el puerto 443 y decide a dónde enviar el tráfico según los primeros bytes del paquete. Si detecta un handshake SSL/TLS, lo manda a tu servidor web. Si detecta un handshake SSH, lo manda a tu demonio SSHD.

Esto mantiene el cifrado nativo de SSH sin envolverlo en nada. El firewall ve tráfico legítimo por el puerto 443 y tu servidor se encarga de desenrutarlo. Puede que en setups con balanceadores de carga muy agresivos el comportamiento de sslh varíe; no pude reproducirlo en todos los casos.

Configurar en la raíz del sitio dentro de /etc/sslh/sslh.cfg:

# /etc/sslh/sslh.cfg
# Escuchamos en todas las interfaces, puerto 443
listen:
(
{ host: "0.0.0.0", port: "443" }
);

protocols:
(
# Si es tráfico web HTTPS, lo mandamos al Nginx local
{ name: "tls", host: "127.0.0.1", port: "8443" },

# Si es SSH, lo mandamos al SSHD local
# Esta comprobación previene enrutado incorrecto de paquetes
{ name: "ssh", host: "127.0.0.1", port: "22" }
);

Esto lo escribo en febrero de 2026 con OpenSSH 9.9. Si llegaste aquí un año después, revisa el changelog de OpenSSH; es posible que traigan opciones nativas de camuflaje de protocolo, aunque la filosofía de no duplicar capas de cifrado seguirá siendo la misma.