Qual é a diferença entre SSL e SSH? O que é mais seguro?

SSL e SSH fornecem a criptografia elementos para construir um túnel para transporte de dados confidenciais com integridade verificada.Para essa parte, eles usam técnicas semelhantes, e podem sofrer o mesmo tipo de ataques, portanto, devem fornecer segurança semelhante (ou seja, boa segurança), assumindo que ambos estão devidamente implementados. A existência de ambos é uma espécie de síndrome NIH : os desenvolvedores SSH deveriam ter reutilizado SSL para a parte do túnel (o protocolo SSL é flexível o suficiente para acomodar muitas variações, inclu não usando certificados).

Eles diferem nas coisas que estão ao redor do túnel. SSL tradicionalmente usa certificados X.509 para anunciar as chaves públicas do servidor e do cliente; SSH tem seu próprio formato. Além disso, o SSH vem com um conjunto de protocolos para o que vai dentro do túnel (multiplexação de várias transferências, realização de autenticação baseada em senha dentro do túnel, gerenciamento de terminal …) enquanto não existe tal coisa em SSL , ou, mais precisamente, quando tais coisas são usadas em SSL, não são consideradas parte de SSL (por exemplo, ao fazer autenticação HTTP baseada em senha em um túnel SSL, dizemos que faz parte de “HTTPS”, mas ele realmente funciona de maneira semelhante ao que acontece com SSH).

Conceitualmente, você poderia pegar o SSH e substituir a parte do túnel pela do SSL. Você também pode pegar HTTPS e substituir o SSL por SSH-with-data-transport e um gancho para extrair a chave pública do servidor de seu certificado. Não há impossibilidade científica e, se feito de maneira adequada, a segurança permaneceria a mesma. No entanto, não existe um conjunto difundido de convenções ou ferramentas existentes para isso.

Portanto, não usamos SSL e SSH para as mesmas coisas, mas isso “é devido às ferramentas que historicamente vêm com as implementações dessas protocolos, não devido a uma diferença relacionada à segurança. E quem quer que implemente SSL ou SSH deve observar que tipo de ataques foram tentados em ambos os protocolos.

Comentários

• Bom trabalho. E, de fato, como o SSH é mais fácil de configurar do que SSL, muitas pessoas fazem um túnel http (não https) dentro do SSH, por exemplo, para fazer a administração remota do sistema com uma web Ferramenta GUI como ebox ou webmin.
• Só para salientar, ‘ não é bem verdade que os caras do SSH ” deveria ” ter usado SSL: SSH foi projetado especificamente para ter uma superfície de ataque pequena e ser muito seguro. SSHv2 não tem nenhum dos problemas e armadilhas em SSL / TLS, então vamos com uma coisa menor que você entendeu bem, com menos complexidade, eles saíram com algo muito mais adequado à sua situação. Depende de quão paranóico você é: SSL não ‘ não pode ser usado, dependendo do aplicativo, mas o design SSH ‘ o torna aceitável em situações / comunidades de segurança onde SSL simplesmente não é confiável.
• @NicholasWilson ” SSH ‘ O design torna-o aceitável em situações / comunidades de segurança onde SSL simplesmente não é confiável ” como …
• SSL e SSH foram desenvolvidos em paralelo (ambos lançados em 1995), portanto, seja SSH mesmo poderia ter usado SSL não está claro. Se ele deveria ter usado o SSL 2.0 contemporâneo também é muito duvidoso 🙂
• Bem, o SSH 2.0 foi uma reescrita completa do protocolo e apareceu por volta de 1999, de modo que alguém poderia ter reutilizado SSL 3.0 ou mesmo TLS 1.0. Mas, é claro, o TLS parece estar empatado com o X.509, o que afugenta os desenvolvedores.

Esta não é uma comparação razoável a se fazer. SSL é um método geral para proteger dados transportados por uma rede, enquanto SSH é um aplicativo de rede para fazer login e compartilhar dados com um computador remoto.

A proteção da camada de transporte no SSH é semelhante em capacidade ao SSL, portanto, o que é “mais seguro” depende do que seu modelo de ameaça específico exige e se as implementações de cada um abordam os problemas com os quais você está tentando lidar.

O SSH então tem uma camada de autenticação do usuário que falta ao SSL (porque não precisa – o SSL só precisa autenticar as duas interfaces de conexão que o SSH também pode fazer). Na arte UTF-8:

 SSL SSH +-------------+ +-----------------+ | Nothing | | RFC4254 | Connection multiplexing +-------------+ +-----------------+ | Nothing | | RFC4252 | User authentication +-------------+ +-----------------+ | RFC5246 | | RFC4253 | Encrypted data transport +-------------+ +-----------------+ 

Com relação ao problema contra o qual há mais ataques em potencial, parece claro que o SSH tem uma superfície de ataque maior. Mas isso “é apenas porque o SSH tem um todo aplic ação incorporada a ele: a superfície de ataque de SSL + qualquer aplicativo que você precisa fornecer não pode ser comparada porque não temos informações suficientes.

Comentários

• -1 É uma comparação razoável. Você incorretamente pressupõe que o OP está comparando o SSL com o programa unix ssh (1) . SSH é na verdade outro protocolo que fornece segurança de camada de transporte, que por acaso tem disposições especiais para shells remotos e execução remota.
• +1 @jpillora embora eu concorde que faz sentido comparar os dois, o termo SSH é normalmente não é usado para se referir ao subconjunto do protocolo SSH que lida com a segurança da camada de transporte que seria diretamente comparável ao SSL / TLS. É quase exclusivamente usado em referência ao protocolo da camada de aplicativo, que difere de SSL / TLS na maneira descrita nesta resposta.
• @freb a maneira como ‘ re referido em geral não muda a verdade da questão. SSH é um protocolo usado como camada de transporte para o utilitário ssh. A resposta aceita e mais votada reflete esse fato.
• @jpillora Eu apenas quis dizer que não ‘ não acho que o protocolo da camada de transporte SSH é o que a maioria das pessoas quer dizer dada a formulação da pergunta. No entanto, dada a resposta que foi aceita como correta, deve ter sido o que o OP estava perguntando.
• @freb Certo, a maioria das pessoas acha isso, dada a formulação, o que torna ainda mais importante corrigir este comum equívoco.

De um ponto de vista criptográfico estrito, ambos fornecem criptografia autenticada, mas em dois jeitos diferentes.

O SSH usa o chamado Encrypt-and-MAC, ou seja, a mensagem cifrada é justaposta a um código de autenticação de mensagem (MAC) da mensagem clara para adicionar integridade. Isso nem sempre é comprovado como totalmente seguro (mesmo se em casos práticos for o suficiente).

SSL usa MAC-then-Encrypt: um MAC é justaposto ao texto não criptografado e ambos são criptografados . Este também não é o melhor, pois com alguns modos de cifra de bloco, partes do MAC podem ser adivinhadas e revelar algo sobre a cifra. Isso levou a vulnerabilidades no TLS 1.0 (ataque BEAST).

Portanto, ambos têm potenciais fraquezas teóricas. O método mais forte é Encrypt-then-MAC (adicione um MAC da mensagem cifrada), que é implementado, por exemplo, em IPsec ESP.

Comentários

• SSH ‘ s protocolo de pacote binário é criptografar e MAC onde para cada mensagem de texto simples (m) ele envia o texto cifrado E (m) ++ MAC (m) (concatenar criptografado mensagem com MAC), versus SSL que faz E (m ++ MAC (m)). No entanto, SSH é muito mais do que apenas seu protocolo de pacote binário (gerenciamento de chaves, cliente / servidor de shell remoto, transferência de arquivos, etc), enquanto SSL (agora chamado de TLS) é apenas o protocolo de camada de transporte usado em outros protocolos na funcionalidade necessária (por exemplo, HTTPS, FTPS, IMAPS etc.). Veja também a comparação de EtM, E & M, MtE em: crypto.stackexchange.com / questions / 202
• Totalmente de acordo, há muito mais do que o que escrevi; isso ‘ é o que eu quis dizer com meu incipit ” de um ponto de vista criptográfico estrito “.
• BEAST não está relacionado a MtE e é devido a known-IV com CBC (em SSL3 e TLS1.0) – que SSH2 também corrige e não corrige, embora tenha CTR como uma alternativa antes dele e TLS teve AEAD = GCM (TLS também CCM) (e ambos ChaCha / Poly) como uma alternativa melhor. Os ataques baseados em preenchimento MtE + CBC são POODLE e Lucky13.
• Eu tenho uma solução que torna o MAC-then-Encrypt seguro para qualquer cifra que tenha tamanho de saída = tamanho de entrada e nenhuma entrada de dados fraca na cifra core.
• esta resposta está desatualizada, pois não é isso que o TLS faz hoje.

Acho que há um aspecto dessa comparação que foi esquecido. user185 chegou perto, mas não chegou lá. Concordo que essas são maçãs e laranjas e sinto uma melhor comparação com HTTPS e SSH. HTTPS e SSH utilizam camadas diferentes do modelo OSI e, portanto, criptografam os dados em diferentes vezes na transmissão. Então, as verdadeiras perguntas que se deveriam fazer seriam em torno de quando esses dados são criptografados e não criptografados durante a transmissão. Isso revelará suas possíveis superfícies de ataque. Com HTTPS, uma vez que o pacote é recebido por um dispositivo em a rede de destino (servidor da Web, roteador de borda, balanceador de carga, etc …) não é criptografada e passa o resto de sua jornada em texto simples. Muitos argumentariam que isso não é um grande problema, pois o tráfego é interno em desta vez, mas se a carga útil contiver dados confidenciais, eles serão armazenados sem criptografia nos arquivos de registro de cada dispositivo de rede por onde passa até chegar ao destino final. Com SSH, normalmente, o dispositivo de destino é especificado e o a transmissão é criptografada até chegar a este dispositivo. Existem maneiras de recriptografar os dados HTTPS, mas essas são etapas extras que a maioria se esquece de executar ao implementar uma solução HTTPS em seu ambiente.

ssh é como uma chave (privada) e a fechadura (pública)

ssl é como a porta e os tijolos.

ssl fornece um link seguro entre os dois servidores de computador. por exemplo, o seu e aquele ao qual está se conectando.

ssh é como o computador conectado pode verificar a si mesmo e obter acesso.

Comentários

• Você não explica o comentário de ” porta e tijolos “. SSL também possui chaves públicas e privadas. SSL também pode ser usado para autenticação de cliente. SSH também fornece um link seguro entre o cliente e o servidor.

SSL é uma camada de protocolo que é abstraído do conteúdo que está sendo encapsulado. SSH é uma versão segura do shell (SH), ele não foi projetado para conter uma camada abstrata abaixo dele, ele foi projetado especificamente para transportar o tráfego do shell. Portanto, embora as operações criptográficas sejam usadas em ambos, e essas operações criptográficas possam até ser as mesmas, o propósito e, portanto, o design geral é bem diferente.

Lembre-se de que há diferenças específicas (conforme já mencionado acima ), mas a maioria, senão todas, essas diferenças estão enraizadas na finalidade dos diferentes protocolos.

Comentários

• -1 Você fez a suposição incorretamente que OP está comparando SSL ao programa unix ssh (1) . SSH é, na verdade, outro protocolo que fornece segurança de camada de transporte, que por acaso tem disposições especiais para shells remotos e execução remota.

Se você realmente está procurando SSH vs SSL (TLS), a resposta é SSH.

Um dos motivos pelos quais o SSH vence o SSL é a maneira como ele executa a autenticação. Por esse motivo, ao usar FTP, use o protocolo SSH (SFTP) em vez de FTPS (FTP sobre SSL).

SSH é usado em redes corporativas para:

• fornecendo acesso seguro para usuários e processos automatizados
• transferências de arquivos interativas e automatizadas
• emissão de comandos remotos

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

Comentários

• ” Por uma razão, SSH vence SSL é a forma como executa a autenticação ” Você tem uma fonte ou explicação para esta afirmação?
• No SSH, existem duas opções para conectar o servidor. Com a opção de autenticação baseada em chave, primeiro será necessário gerar uma chave privada SSH e uma chave pública de antemão. O que não é muito trabalho adicional. Isso também é considerado as melhores práticas de segurança. SSL tem tantas versões que a mais recente é a TLS1.2.O que significa que ‘ ainda não é tão seguro, mas está em processo de melhorar.
• O TLS também tem certificados do lado do cliente. Você não explica por que SSH ” ganha “.
• Se você for copiar / colar de algum lugar, certifique-se de citar sua fonte.
• ” SSL tem tantas versões ” Portanto, 6 versões são ” tantos “? OpenSSH está na versão 7.7. ” O que significa que ‘ ainda não é tão seguro, mas está em vias de melhorar. ” Sua lógica não faz sentido aqui.

O problema é duplo, ” Não é apenas a força e a fraqueza da criptografia. Mas é a facilidade e conveniência da entrega. Portanto, da perspectiva de negócios, SSL / TLS é mais conveniente e fácil porque requer apenas um navegador e um certificado público ou privado.

E o SSH requer o aplicativo ou o thin client instalado para usá-lo. Isso é mais um problema da perspectiva e do suporte do cliente da Internet do usuário.