Journal OpenSSH No Longer Has To Depend On OpenSSL

Posté par  . Licence CC By‑SA.
Étiquettes :
16
22
sept.
2015

Cher Nal,

durant mes pérégrinations sur la toile, je suis tombé sur un article mentionnant l'adoption du cipher Poly1305 dans OpenSSH, ce qui amène à la possibilité de défaire la dépendance entre SSL et SSH.

L'option de compilation "make OPENSSL=no" est désormais réalité.

http://it.slashdot.org/story/14/04/30/1822209/openssh-no-longer-has-to-depend-on-openssl

Bon OK je suis en retard d'un an, l'article est pas frais etc etc…

Bref, le but de ce journal n'est pas de faire étalage d'une nouveauté d'il y a un an mais plutôt de récolter des retours d'expérience parmi vous.

Existe t-il des distributions Linux offrant cette possibilité ?

Avez-vous recompilé SSH pour vous défaire du carcan SSL ?

De mon côté, ne travaillant pas sous Linux mais sur un autre Unix, je dois recompiler SSH afin de mettre à jour mon parc d'environ 1000 machines, et du coup je suis bien tenté par l'aventure.

Mais j'aimerais éviter d'essuyer les plâtres autant que possible. De toute manière nous sommes des professionnels, on fera retour arrière si ça merde trop :-)

  • # Que de questions

    Posté par  . Évalué à 4.

    Tant de questions, et très intéressantes de surcroît. Ça aurait mérité une demande d'aide dans le forums.

    De toute manière, nous sommes des professionnels

    En tant que professionnel, il y a des procédures à respecter, sinon, c'est le début de la chienlit

    Cordialement,

    Lead Senior Management of trolling archiving since 1515 Marignan

  • # Le mauvais pro et le bon pro

    Posté par  . Évalué à 10.

    De toute manière nous sommes des professionnels, on fera retour arrière si ça merde trop :-)

    Le vrai pro le fait direct en prod sans downgrade possible. C'est normal, c'est un vrai pro ;)

  • # Quel objectif ?

    Posté par  . Évalué à 4.

    Quel est le soucis avec OpenSSL ?

    Si on supprime la dépendance à OpenSSL, cela implique de mettre à jour les clients ?

    • [^] # Re: Quel objectif ?

      Posté par  . Évalué à 3.

      cela implique en effet que les clients soient suffisamment récents pour prendre en charge les ciphers en question.

      Quant à la dépendance à openssl, je ne vais pas te dresser la liste des CVE qui sont parus entre 2014 et 2015 mais ils sont nombreux et critiques pour certains.

      Que je sache cela n'a en revanche jamais porté atteinte à SSH directement pour le moment, mais cette dépendance ne me plait guère et ne rassure pas pour l'avenir.

      Alors si on peut rendre SSH un peu plus autonome et mieux maîtriser la maintenance (un seul soft plutôt que deux), ce n'est pas plus mal.

      • [^] # Re: Quel objectif ?

        Posté par  . Évalué à 10.

        Les CVE d'OpenSSL n'ont pas grande importance s'ils affectent des parties qui ne sont pas utilisées par OpenSSH. Vu que SSH est un protocol distinct de SSL, c'est probablement juste la partie calculatoire (implémentations des algos de chiffrement et signature) qui est utilisée, et là je doute qu'il y ait beaucoup de problèmes.

  • # OpenSSH sans OpenSSL, ça marche

    Posté par  . Évalué à 5. Dernière modification le 23 septembre 2015 à 15:54.

    ça marche mais au prix de devoir regénérer toutes les paires de clefs au format ed25519 puisque les clefs RSA & DSA ne sont plus prises en charge.

    Mais ça on s'en doutait un peu.

    Une chose à savoir pour que la compilation passe avec la version portable et sous AIX (bien que je pense que ça n'a rien de spécifique à AIX), il faut modifier la ligne 5774 du script "configure" :

    openssl=yes ==> openssl=no

    Cette modification est nécessaire même si on appelle correctement "configure" avec les options qui vont bien (à adapter selon votre environnement) : 

        ./configure \
                    --without-ssl \
                    --without-openssl-header-check \
                    --without-ssh1 \
                    --build=powerpc-ibm-aix \
                    --prefix=/etc/ssh \
                    --sysconfdir=/etc/ssh \
                    --exec-prefix=/etc/ssh \
                    --with-zlib=/opt/freeware \
                    --with-pid-dir=/var/run \
                    --bindir=/usr/bin \
                    --sbindir=/usr/sbin \
                    --libexecdir=/usr/sbin \
                    --mandir=/usr/share/man \
                    --sharedstatedir=/etc/ssh/share \
                    --with-privsep-path=/var/empty

    Une autre chose à savoir est celle concernant les ciphers, vos clients doivent prendre en charge le chacha20 et poly1305.

    http://it.slashdot.org/story/13/12/11/173213/openssh-has-a-new-cipher-chacha20-poly1305-from-dj-bernstein

    Puis enfin, si vos sshd_config font appel au mauvais format de clefs ou de cipher, sshd ne démarrera pas, evidemment.

    Hope this helps.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.