¿Cuál es la diferencia entre SSL y SSH? ¿Cuál es más seguro?

Tanto SSL como SSH proporcionan la información criptográfica elementos para construir un túnel para el transporte de datos confidenciales con integridad comprobada. Para esa parte, utilizan técnicas similares y pueden sufrir el mismo tipo de ataques, por lo que deben proporcionar una seguridad similar (es decir, buena seguridad) asumiendo que ambos están correctamente implementados. Que ambos existan es una especie de síndrome de NIH : los desarrolladores de SSH deberían haber reutilizado SSL para la parte del túnel (el protocolo SSL es lo suficientemente flexible para adaptarse a muchas variaciones, incluido ding sin usar certificados).

Se diferencian en las cosas que están alrededor del túnel. SSL tradicionalmente usa certificados X.509 para anunciar claves públicas de servidor y cliente; SSH tiene su propio formato. Además, SSH viene con un conjunto de protocolos para lo que va dentro del túnel (multiplexando varias transferencias, realizando autenticación basada en contraseña dentro del túnel, administración de terminales …) mientras que no existe tal cosa en SSL. o, más exactamente, cuando tales cosas se utilizan en SSL, no se consideran parte de SSL (por ejemplo, cuando se realiza una autenticación HTTP basada en contraseña en un túnel SSL, decimos que es parte de «HTTPS», pero realmente funciona de una manera similar a lo que sucede con SSH).

Conceptualmente, podría tomar SSH y reemplazar la parte del túnel con la de SSL. También puede tomar HTTPS y reemplazar el SSL con SSH-with-data-transport y un gancho para extraer la clave pública del servidor de su certificado. No hay imposibilidad científica y, si se hace correctamente, la seguridad seguirá siendo la misma. Sin embargo, no existe un conjunto generalizado de convenciones o herramientas existentes para eso.

Por lo tanto, no usamos SSL y SSH para las mismas cosas, pero eso se debe a las herramientas que históricamente vienen con las implementaciones de esos protocolos, no debido a una diferencia relacionada con la seguridad. Y a quien implemente SSL o SSH se le aconsejará que mire qué tipo de ataques se probaron en ambos protocolos.

Comentarios

• Buen trabajo. Y de hecho, dado que SSH es más fácil de configurar que SSL, muchas personas hacen un túnel http (no https) dentro de SSH, por ejemplo, para realizar la administración remota del sistema con una web Herramienta de GUI como ebox o webmin.
• Solo para señalar, ‘ no es del todo cierto que los chicos de SSH » debería » haber usado SSL: SSH fue diseñado muy específicamente para tener una pequeña superficie de ataque y ser muy seguro. SSHv2 no tiene ninguno de los problemas y trampas en SSL / TLS, por lo que ir con algo más pequeño que ellos u entendido bien, con menos complejidad, salieron con algo mucho más adecuado a su situación. Depende de lo paranoico que estés: SSL no ‘ t inutilizable, según la aplicación, pero el diseño de SSH ‘ lo hace aceptable en situaciones / comunidades de seguridad donde SSL simplemente no es de confianza.
• El diseño de @NicholasWilson » SSH ‘ lo hace aceptable en situaciones / comunidades de seguridad donde SSL simplemente no es de confianza » como …
• SSL y SSH se desarrollaron en paralelo (ambos se lanzaron en 1995), así que si SSH incluso podría haber usado SSL no está claro. Si debería haber utilizado el SSL 2.0 contemporáneo también es muy dudoso 🙂
• Bueno, SSH 2.0 fue una reescritura completa del protocolo y apareció en algún momento alrededor de 1999, por lo que se podría haber reutilizado SSL 3.0 o incluso TLS 1.0. Pero, por supuesto, TLS parece estar vinculado con X.509, lo que asusta a los desarrolladores.

Desde un punto de vista criptográfico estricto, ambos proporcionan cifrado autenticado, pero en dos diferentes caminos.

SSH utiliza el denominado cifrado y MAC, es decir, el mensaje cifrado se yuxtapone a un código de autenticación de mensaje (MAC) del mensaje claro para agregar integridad. No se ha demostrado que esto sea siempre completamente seguro (incluso si en casos prácticos debería ser suficiente).

SSL usa MAC-then-Encrypt: una MAC se yuxtapone al texto sin cifrar, luego ambos están encriptados . Este tampoco es el mejor, ya que con algunos modos de cifrado de bloques, se pueden adivinar partes del MAC y revelar algo en el cifrado. Esto llevó a vulnerabilidades en TLS 1.0 (ataque BEAST).

Por lo tanto, ambos tienen posibles debilidades teóricas. El método más fuerte es Encrypt-then-MAC (agregar una MAC del mensaje cifrado), que se implementa, por ejemplo, en IPsec ESP.

Comentarios

• SSH ‘ s protocolo de paquete binario es cifrado y MAC donde para cada mensaje de texto plano (m) envía el texto cifrado E (m) ++ MAC (m) (concatenar cifrado mensaje con MAC), versus SSL que hace E (m ++ MAC (m)). Sin embargo, SSH es mucho más que su protocolo de paquetes binarios (administración de claves, cliente / servidor shell remoto, transferencia de archivos, etc.), mientras que SSL (ahora llamado TLS) es solo el protocolo de capa de transporte que se usa en otros protocolos que agregan en la funcionalidad necesaria (por ejemplo, HTTPS, FTPS, IMAPS, etc.). Consulte también la comparación de EtM, E & M, MtE en: crypto.stackexchange.com / questions / 202
• Totalmente de acuerdo, hay mucho más de lo que escribí; que ‘ es lo que quise decir con mi incipit » desde un estricto punto de vista criptográfico «.
• BEAST no está relacionado con MtE y se debe a known-IV con CBC (en SSL3 y TLS1.0), que SSH2 también hace y no corrige, aunque obtuvo CTR como alternativa antes de que tanto él como TLS obtuvieron AEAD = GCM (TLS también CCM) (y ambos ChaCha / Poly) como una mejor alternativa. Los ataques basados en relleno MtE + CBC son POODLE y Lucky13.
• Tengo una solución que hace que MAC-then-Encrypt sea seguro para cualquier cifrado que tenga tamaño de salida = tamaño de entrada y sin entrada de datos débiles en el cifrado core.
• esta respuesta está desactualizada ya que esto no es lo que hace TLS hoy.

Creo que hay un aspecto de esta comparación que se pasó por alto. user185 estuvo cerca, pero no llegó allí. Estoy de acuerdo en que se trata de manzanas y naranjas y siento una mejor comparación entre manzanas y manzanas al ser HTTPS y SSH. HTTPS y SSH utilizan diferentes capas del modelo OSI y, por lo tanto, cifran los datos en diferentes veces en la transmisión. Entonces, las preguntas reales que uno debería hacerse serían en la línea de cuándo se cifran y desencriptan estos datos durante la transmisión. Esto revelará sus posibles superficies de ataque. Con HTTPS, una vez que un dispositivo recibe el paquete en la red de destino (servidor web, enrutador de borde, balanceador de carga, etc.) no está encriptada y pasa el resto de su viaje en texto sin formato. Muchos dirían que esto no es un gran problema ya que el tráfico es interno en esta vez, pero si la carga contiene datos confidenciales, se almacena sin cifrar en los archivos de registro de cada dispositivo de red por el que pasa hasta que llega a su destino final. Con SSH, normalmente, se especifica el dispositivo de destino y el la transmisión está encriptada hasta que llega a este dispositivo. Hay formas de volver a cifrar los datos HTTPS, pero estos son pasos adicionales que la mayoría olvida tomar al implementar una solución HTTPS en su entorno.

ssh es como una llave (privada) y la cerradura (pública)

ssl es como la puerta y los ladrillos.

ssl proporciona un enlace seguro entre dos servidores informáticos. por ejemplo, el suyo y al que se está conectando.

ssh es la forma en que la computadora que se conecta puede verificarse y obtener acceso.

Comentarios

• No explica el comentario de » puerta y ladrillos » en absoluto. SSL también tiene claves públicas y privadas. SSL también se puede utilizar para la autenticación de clientes. SSH también proporciona un enlace seguro entre el cliente y el servidor.

SSL es una capa de protocolo que se abstrae del contenido que se tuneliza. SSH es una versión segura de shell (SH), no fue diseñado para contener una capa abstracta debajo, fue diseñado específicamente para transportar tráfico de shell. Entonces, aunque las operaciones criptográficas se utilizan en ambos, y esas operaciones criptográficas podrían incluso ser las mismas, el propósito y, por lo tanto, el diseño general es bastante diferente.

Tenga en cuenta que existen diferencias específicas (como se ha citado anteriormente ), pero la mayoría, si no todas, esas diferencias tienen su origen en el propósito de los diferentes protocolos.

Comentarios

• -1 Usted asume incorrectamente ese OP está comparando SSL con el programa Unix ssh (1) . SSH es en realidad otro protocolo que proporciona seguridad en la capa de transporte, que tiene disposiciones especiales para shells remotos y ejecución remota.

Si realmente busca SSH vs SSL (TLS), entonces la respuesta es SSH.

Una de las razones por las que SSH gana sobre SSL es la forma en que realiza la autenticación. Por esta razón, cuando use FTP, use el protocolo SSH (SFTP) en lugar de FTPS (FTP sobre SSL).

SSH se usa en redes corporativas para:

• proporcionando acceso seguro para usuarios y procesos automatizados
• transferencias de archivos interactivas y automatizadas
• emitiendo comandos remotos

fuente: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

Comentarios

• » Por una razón, SSH gana sobre SSL es la forma en que realiza la autenticación » ¿Tiene una fuente o explicación para esta afirmación?
• En SSH uno tiene dos opciones para conectar el servidor. Con la opción de autenticación basada en clave, primero deberá generar una clave privada SSH y una clave pública de antemano. Lo que no supone mucho trabajo adicional. Esto también se considera las mejores prácticas de seguridad. SSL tiene tantas versiones, la última es TLS1.2.Lo que significa que ‘ aún no es tan seguro, pero está en proceso de mejorar.
• TLS también tiene certificados del lado del cliente. No explica por qué SSH » gana «.
• Si va a copiar / pegar desde algún lugar, asegúrese de citar su fuente.
• » SSL tiene tantas versiones » Por lo tanto, 6 versiones son » ¿tantos «? OpenSSH está en la versión 7.7. » Lo que significa que ‘ aún no es tan seguro, pero está en proceso de mejorar. » Tu lógica no tiene sentido aquí.

El problema es doble, » No es solo la fortaleza y la debilidad del cifrado, sino la facilidad y conveniencia de la entrega. Entonces, desde la perspectiva comercial, SSL / TLS es más conveniente y más fácil porque solo requiere un navegador y un certificado público o privado.

Y SSH requiere la aplicación o el cliente ligero instalado para usarlo. Eso es más un problema desde la perspectiva y el soporte del cliente de Internet del usuario.