Existem benefícios de segurança na implantação de grupos SSH DH personalizados em sistemas somente para clientes?

16

Uma estratégia mitigativa sugerida contra ataques relacionados ao Logjam no SSH é gerar grupos SSH Diffie-Hellman personalizados usando algo como (o abaixo é para o OpenSSH)

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

seguido pela substituição do arquivo de módulos de todo o sistema pelo arquivo de saída moduli-2048. ( ssh-keygen -Gé usado para gerar candidatos DH-GEX primos e ssh-keygen -Tpara testar os candidatos gerados quanto à segurança.)

Isso é claramente uma coisa razoável a se fazer nos servidores SSH que, de outra forma, usariam grupos conhecidos que se prestam bem à pré-computação, mas existem benefícios de segurança na implantação de grupos SSH DH personalizados em sistemas somente para clientes? (Ou seja, sistemas que se conectam a servidores SSH, mas nunca agem como um servidor SSH.)

Estou interessado principalmente em respostas relacionadas ao OpenSSH no Linux, mas respostas mais genéricas também serão apreciadas.

ssh ssh-keys logjam

— um CVn
fonte

18

Você pode, se realmente quiser, mas eu não me incomodaria em regenerar os parâmetros DH de 2048 bits para o OpenSSH. Há coisas muito mais importantes que você precisa fazer para proteger o SSH, como desativar a criptografia fraca .

O que eu faria é excluir os existentes com menos de 2048 bits.

awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli

Caso você não tenha notado, o OpenSSH é fornecido com um grande número de módulos pré-gerados, até 8192 bits. Embora certamente nos preocupemos com os primos de 1024 bits hoje, acredita-se que os de 2048 bits sejam seguros para o futuro próximo. E embora isso acabe mudando, pode ser na próxima semana, mas é mais provável que demore muito tempo depois que nos tornarmos pensionistas ...

Há também este trecho curioso na ssh-keygenpágina do manual:

É importante que este arquivo contenha módulos de vários comprimentos de bits e que ambas as extremidades de uma conexão compartilhem módulos comuns.

O que parece argumentar contra a substituição de módulos existentes, embora não forneça realmente o motivo real para fazê-lo.

— Michael Hampton
fonte

Relacionado: Diffie-Hellman usando um módulo diferente em ambos os lados na criptografia . Para meu entendimento limitado, parece que, se não houver módulos compartilhados de um comprimento desejado, Diffie-Hellman com um grupo desse comprimento não será possível no caso geral e poderá não ser possível em nenhum caso específico. Portanto, o compartilhamento de módulos entre os dois pontos de extremidade é um requisito matemático do protocolo de troca de chaves Diffie-Hellman e a tentativa de realizar uma troca de chaves Diffie-Hellman entre dois pontos de extremidade que não possuem módulos comuns falhará.

— um CVn

2

O RFC 4419 [ tools.ietf.org/html/rfc4419] é precisamente para permitir que o servidor forneça parâmetros DH personalizados. O servidor envia seus parâmetros candidatos ao cliente e, se o cliente concordar, os dois lados usam os parâmetros fornecidos pelo servidor para gerar um segredo compartilhado que é usado como chave da sessão. Portanto, não há problema se o servidor e o cliente não tiverem as mesmas entradas em seu arquivo de módulo.

— 18718 Brian Minton

2

A resposta é: Não. Não há benefícios. :)

/etc/ssh/moduli O arquivo é usado apenas para o lado do servidor.

Você não precisa se preocupar com esse arquivo no lado do cliente SSH:

Você pode rastrear a execução do cliente SSH e verificar se ele não abre esse arquivo.

$ strace -e openat ssh user@localhost

— Adi Roiban
fonte