Comment désactiver SSLv3 sur un serveur OpenSSH SSH pour éviter POODLE?

À la suite de la vulnérabilité POODLE récemment découverte , je voudrais désactiver SSLv3 sur tous mes serveurs SSH. Comment y parvenir avec OpenSSH?

— drs
source

N'est même pas affecté, consultez CVE-2014-3566

— Braiam

@Braiam, j'ai été invité à poser cette question car l'article lié conseille aux utilisateurs de sécuriser leurs serveurs SSH contre cette vulnérabilité.

— drs

C'était leur erreur. Google, celui qui l'a découvert n'a rien dit sur SSH.

— Braiam

-1 car SSH et SSL / TLS sont deux protocoles complètement différents. ZDnet n'est pas une source technique fiable.

— bortzmeyer

@bortzmeyer alors que techniquement vous avez raison, la question n'est pas si mauvaise. Et beaucoup de gens demandent probablement la même chose.

— peterph

Ce n'est pas un problème pour OpenSSH car il n'utilise pas SSL.

extrait - Quelle est la différence entre SSL et SSH? Quel est le plus sûr?

Ils diffèrent sur les choses qui sont autour du tunnel. SSL utilise traditionnellement des certificats X.509 pour annoncer les clés publiques du serveur et du client; SSH a son propre format. De plus, SSH est livré avec un ensemble de protocoles pour ce qui se passe à l'intérieur du tunnel (multiplexage de plusieurs transferts, exécution d'une authentification par mot de passe dans le tunnel, gestion de terminal ...) alors qu'il n'y a rien de tel dans SSL, ou, plus précisément, quand ces choses sont utilisées dans SSL, elles ne sont pas considérées comme faisant partie de SSL (par exemple, lorsque vous faites une authentification HTTP basée sur un mot de passe dans un tunnel SSL, nous disons que cela fait partie de "HTTPS", mais cela fonctionne vraiment d'une manière similaire à ce qui se passe avec SSH).

Conceptuellement, vous pouvez prendre SSH et remplacer la partie tunnel par celle de SSL. Vous pouvez également prendre HTTPS et remplacer le truc SSL par SSH-with-data-transport et un hook pour extraire la clé publique du serveur de son certificat. Il n'y a aucune impossibilité scientifique et, si elle est effectuée correctement, la sécurité resterait la même. Cependant, il n'y a pas d'ensemble de conventions ou d'outils existants à ce sujet.

Comme preuve supplémentaire, je vous dirigerais vers la RFC 4253 , qui traite du «protocole de couche de transport Secure Shell (SSH)». Il s'agit de la couche de transport personnalisée de SSH, elle n'utilise pas la même que celle utilisée par HTTPS / SSL.

Ce document décrit le protocole de couche de transport SSH, qui s'exécute généralement au-dessus de TCP / IP. Le protocole peut être utilisé comme base pour un certain nombre de services réseau sécurisés. Il offre un cryptage solide, une authentification du serveur et une protection de l'intégrité. Il peut également fournir une compression.

Enfin, ce Q & A du site de sécurité SE intitulé: SSL3 "Poodle" Vulnerability avait ceci à dire sur l'attaque POODLE.

extrait

L'attaque Poodle fonctionne dans un contexte de texte en clair choisi, comme BEAST et CRIME avant elle. L'attaquant s'intéresse aux données protégées par SSL et il peut:

injecter ses propres données avant et après la valeur secrète qu'il souhaite obtenir;

inspecter, intercepter et modifier les octets résultants sur le fil.

Le scénario principal et à peu près uniquement plausible où de telles conditions sont remplies est un contexte Web: l'attaquant exécute un faux point d'accès WiFi et injecte son propre Javascript dans le cadre d'une page Web (HTTP, pas HTTPS) que la victime parcourt. Le Javascript malveillant fait que le navigateur envoie des demandes à un site HTTPS (par exemple, un site Web de banque) pour lequel le navigateur de la victime a un cookie. L'attaquant veut ce cookie.

Il n'y a donc aucune action à entreprendre pour OpenSSH contre cette menace particulière.

Références

Plus de lecture

Vulnérabilité «Poodle» dans SSL3

— slm
source