SSH + RC4 Cipher: Exatamente o que está em risco?

Question

Eu tenho uma situação em que uma máquina Windows lenta precisa fazer conexões automatizadas periódicas com outra máquina via SSH. O desempenho do SSH nesta máquina lenta é tão ruim que na verdade se tornou um pequeno problema. Eu já sugeri substituir a máquina com problema por uma mais rápida, mas foi derrubada.

Estou pensando em tentar a arc-aura -aka RC4 -cipher com SSH na máquina lenta. Eu li que é menos seguro, mas mais rápido que o AES ou o blowfish. Então, o que exatamente estaria em risco? Meu entendimento é que há três coisas que o SSH oferece segurança:

1. A privacidade dos dados comunicados via SSH
2. Garantia do servidor que o cliente é quem ele afirma ser. Ou seja, combinação válida de nome de usuário + senha / chave SSH.
3. Asurrance ao cliente que a máquina do servidor é quem afirma ser, através das chaves no diretório / etc do servidor.

Para o meu caso específico, podemos viver com uma segurança muito baixa para # 1, # 2 é problemático, mas não é um problema no negócio. Para esta máquina lenta, o # 3 também é aceitável. Mas eu estou preocupado com o # 3 sendo de alguma forma impactado por outros clientes.

A conta que está sendo conectada no servidor é desprivilegiada e já está bem bloqueada, então qualquer um que se conecte como aquele usuário não deve ser capaz de fazer algo óbvio, como alterar arquivos críticos no servidor. Mas um atacante poderia fazer algo como ganhar algum tipo de insight nas chaves do servidor se ele pudesse quebrar transações feitas com as sessões mais fracas do RC4? Qual dos três aspectos acima mencionados usa uma cifra mais fraca colocada em risco?

P.S .: O recurso de compartilhamento de conexão do SSH provavelmente seria a melhor resposta, mas infelizmente não parece ser suportado no Windows. Além disso, usar o código blowfish em vez do AES oferece alguma melhoria, mas ainda é muito ruim.

    

Answer 1

O SSH validará o servidor com base na assinatura da chave pública usada (um simples hash). Cabe ao usuário certificar-se de que a assinatura é válida (ou seja, você normalmente precisa de um canal seguro para isso também; na prática, os clientes geralmente só lembram da primeira assinatura enviada pelo servidor e simplesmente avisam se essa assinatura mudou). p>

Isso significa que a validação do servidor (correta ou incorretamente) não será influenciada por sua seleção de algoritmo simétrico de criptografia.

Dito isso, posso garantir que a alteração da criptografia simétrica de AES para RC4 não trará nenhuma melhoria perceptível no desempenho: mesmo com um processador muito lento (ou deficiente), a diferença de velocidade entre os dois não serão notados.

Se você precisar de mais informações, alguém realmente realizou uma análise detalhada se os resultados de AES vs RC4 (incluindo vários modos de operação para AES)

    

Answer 2

Não sou especialista nisso, mas (assumindo que o problema é com as cifras) usar RC4 não ajuda a autenticar o servidor - RC4 é usado como algoritmo de criptografia simétrica e não a fase de configuração de conexão assimétrica (onde Identidade do IIRC é determinada). Talvez um método baseado em PSK seja um método mais apropriado para evitar problemas de desempenho devido à sobrecarga de computação?